Hibernate-reactive: فشل المثال مع ORM 5.4.24

عفوا ، أنت على حق: لقد فاتنا أنا وسان هذا بسبب إخفاقات زائفة أخرى في CI.

أخاطر بتخمين أن هذا مرتبط بالرقم 443.

هل هذه المشكلة متعلقة بـ DirtyChecking؟
أعتقد أن هذه المشكلة مرتبطة بهذا: https://github.com/hibernate/hibernate-reactive/issues/447

على أي حال ، يحدث ذلك بعد التحديث إلى ORM 5.4.24

هل هذه المشكلة متعلقة بـ DirtyChecking؟

حسنًا ، اكتشفت أن الخطأ مرتبط بتحميل الدُفعات. قد أكون على خطأ على الرغم من.

هل هذه المشكلة متعلقة بـ DirtyChecking؟

حسنًا ، اكتشفت أن الخطأ مرتبط بتحميل الدُفعات. قد أكون على خطأ على الرغم من.

حسنًا ، يبدو أنني مخطئ والمشكلة موجودة بالفعل في مكان آخر.

أنا أعمل على حالة اختبار. آمل أن أكون قادرًا على تأكيد ذلك قريبًا بما فيه الكفاية.

هذا منطقي لأن المثال فقط يفشل وهو المكان الوحيد الذي نقوم فيه بتمكين تحسينات الرمز الثانوي

حسنا عظيم.

لذا نعم. تكمن المشكلة في الفحص القذر للمجموعة عند تمكين تحسينات رمز البايت. لا أعرف لماذا كان يعمل من قبل. من المحتمل أن هذا الخطأ في ORM كان يخفي المشكلة والآن بعد أن تم إصلاحه نراه.

Uff ، يا لها من بيتا.

OTOH ، لماذا يتم فحص المجموعة المتسخة حتى _المادة_ بينما ليس لدينا حتى CollectionPersister s حتى الآن؟

هذه هي المشكلة:

تم تغيير الطريقة المحسّنة $$_hibernate_hasDirtyAttributes ، من

    public boolean $$_hibernate_hasDirtyAttributes() {
        boolean var1 = false;
        var1 = this.$$_hibernate_tracker != null && !this.$$_hibernate_tracker.isEmpty();
        return var1;
    }

إلى

    public boolean $$_hibernate_hasDirtyAttributes() {
        boolean var1 = false;
        var1 = this.$$_hibernate_tracker != null && !this.$$_hibernate_tracker.isEmpty() || this.$$_hibernate_areCollectionFieldsDirty();
        return var1;
    }

    public boolean $$_hibernate_areCollectionFieldsDirty() {
        boolean var1 = false;
        if (!var1 && this.$$_hibernate_collectionTracker != null) {
            if (this.movies == null && this.$$_hibernate_collectionTracker.getSize("movies") != -1) {
                var1 = true;
            } else if (this.movies != null && this.$$_hibernate_collectionTracker.getSize("movies") != this.movies.size()) {
                var1 = true;
            }
        }

        return var1;
    }

الاستدعاء إلى this.movies.size() يتسبب في LazyInitializationException

movies هو اسم الرابطة داخل الاختبار الذي قمت بإنشائه

DavideD ، هل تعتقد أن ما يحدث هنا هو أننا لا نملك init كسول شفاف (أي أنه يفتقد مكالمة إلى fetch() ) ، أم أنه شيء أعمق؟

DavideD لقد علقت على https://github.com/hibernate/hibernate-orm/pull/3645 ، لأن هذه المكالمة إلى size() لا تبدو مناسبة لي. (لكن من السهل أن أفتقد شيئًا ما).

DavideD ، هل تعتقد أن ما يحدث هنا هو أننا لا نملك init كسول شفافة (أي أنه يفتقد استدعاء لجلب ()) ، أم أنه شيء أعمق؟

أعتقد أن هذه هي المشكلة. أحاول معرفة ما إذا كان بإمكاني إحضار المجموعة في مكان ما بحيث يتم جلبها بالفعل.
بالمناسبة ، كل شيء يعمل إذا قمت بتعيين الارتباط لجلب EAGER.

أحاول معرفة ما إذا كان بإمكاني إحضار المجموعة في مكان ما بحيث يتم جلبها بالفعل.

حسنًا ، لكن لا تقتل نفسك في هذا _ حق الآن_ لأنه لا يزال من الخطأ بالنسبة لي أننا نجلب ارتباطًا لم يتم إحضاره بـ mappedBy لمجرد التحقق من عناصره بطريقة قذرة. دعونا نرى ما يجب أن يقوله Sanne .

(OTOH ، حتى لو لم تفعل النواة الشيء الصحيح _ في هذه الحالة بالذات_ ، فقد لا نزال بحاجة إلى الإصلاح الذي تعمل عليه في حالات أخرى.)

للحصول على معلومات إضافية ، هذا فرع مع حالة الاختبار (لا يزال العمل قيد التقدم): https://github.com/DavideD/hibernate-reactive/tree/447-dirtychecking

اختبار:
https://github.com/DavideD/hibernate-reactive/blob/447-dirtychecking/it-bytecode-enhancements/src/test/java/org/hibernate/reactive/it/bytecodeenhancements/BytecodeTest.java

جهات:
https://github.com/DavideD/hibernate-reactive/tree/447-dirtychecking/it-bytecode-enhancements/src/main/java/org/hibernate/reactive/it/bytecodenhancements

شكراgavinking

لماذا مجموعة الافلام != null ؟ حاولت إعادة إنتاج هذا في جوهره ، لكنني لم أستطع لأن مثل هذه المجموعة يجب ألا تكون خالية أبدًا إذا كانت كسولة.

حسنًا ، أذكر أنه كان هناك نقاش طويل نوعًا ما في مكان ما. قضية فتحتها حيث جادلت أن هذا "الكسل المزدوج" أو المجموعات كانت سيئة على الأقل في Hibernate ORM ، ومشكلة أسوأ بكثير بالنسبة للموارد البشرية ، حيث لا يكون الجلب شفافًا. نحتاج إلى السماح لك بالحصول على مرجع للمجموعة لاستدعاء fetch() عليها.

موافق وجدت ذلك. هل يمكن أن يكون هذا مرتبطًا بالرقم 374؟

و https://github.com/hibernate/hibernate-orm/pull/3558

هل collectionsInDefaultFetchGroupEnabled صحيحًا دائمًا في RX؟

حسنًا ، إذا قمت بضبطها على "true" ، فستتم تهيئة المجموعة بشغف.

هل collectionsInDefaultFetchGroupEnabled صحيحًا دائمًا في RX؟

نعم إنه كذلك.

حسنًا ، إذا قمت بضبطها على "true" ، فستتم تهيئة المجموعة بشغف.

امممم ... حقا؟ لم يكن هذا هو القصد!

collectionsInDefaultFetchGroupEnabled المفترض أن يقوم collectionsInDefaultFetchGroupEnabled بتضمين وكيل المجموعة فقط في مجموعة الجلب الافتراضية. ليس من المفترض في الواقع جلب المجموعة نفسها.

لذلك إما أن أكون قد أخفقت تمامًا ، أو أن شيئًا ما قد تغير منذ أن كتبت هذا الرمز.

أنا معك أن النهج الحالي للتحسين ليس مثاليًا وأنه يجب تهيئة الحقل إلى مجموعة ثابتة ، لكنني أعتقد أن المشكلة التي تواجهها في RX قد تكون ناجمة عن شيء آخر. عندما أضبط العلم على صواب ، أرى أن المجموعة تتم تهيئتها من خلال هذا التتبع:

org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:585)
org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:149)
org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:178)
org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:163)
org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:264)
org.hibernate.collection.internal.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:162)
org.hibernate.collection.internal.PersistentBag.size(PersistentBag.java:371)
org.hibernate.test.bytecode.enhancement.dirty.DirtyTrackingCollectionTest$StringsEntity.$$_hibernate_removeDirtyFields(DirtyTrackingCollectionTest.java)
org.hibernate.test.bytecode.enhancement.dirty.DirtyTrackingCollectionTest$StringsEntity.$$_hibernate_clearDirtyCollectionNames(DirtyTrackingCollectionTest.java)
org.hibernate.test.bytecode.enhancement.dirty.DirtyTrackingCollectionTest$StringsEntity.$$_hibernate_clearDirtyAttributes(DirtyTrackingCollectionTest.java)
org.hibernate.tuple.entity.PojoEntityTuplizer.afterInitialize(PojoEntityTuplizer.java:228)
org.hibernate.persister.entity.AbstractEntityPersister.afterInitialize(AbstractEntityPersister.java:5093)
org.hibernate.engine.internal.TwoPhaseLoad.afterInitialize(TwoPhaseLoad.java:405)
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.afterInitialize(AbstractRowReader.java:271)
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:214)
org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:96)
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:105)
org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:285)
org.hibernate.persister.entity.AbstractEntityPersister.doLoad(AbstractEntityPersister.java:4441)
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4431)
org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:569)
org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:537)
org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:208)
org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:332)
org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:108)
org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:74)
org.hibernate.event.service.internal.EventListenerGroupImpl.fireEventOnEachListener(EventListenerGroupImpl.java:121)
org.hibernate.internal.SessionImpl.fireLoadNoChecks(SessionImpl.java:1186)
org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1175)
org.hibernate.internal.SessionImpl.access$2100(SessionImpl.java:193)
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.doLoad(SessionImpl.java:2786)
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.lambda$load$1(SessionImpl.java:2767)
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.perform(SessionImpl.java:2723)
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2767)
org.hibernate.internal.SessionImpl.find(SessionImpl.java:3322)
org.hibernate.internal.SessionImpl.find(SessionImpl.java:3284)
org.hibernate.test.bytecode.enhancement.dirty.DirtyTrackingCollectionTest.lambda$test$1(DirtyTrackingCollectionTest.java:57)
org.hibernate.testing.transaction.TransactionUtil.doInJPA(TransactionUtil.java:235)
org.hibernate.testing.transaction.TransactionUtil.doInJPA(TransactionUtil.java:276)
org.hibernate.test.bytecode.enhancement.dirty.DirtyTrackingCollectionTest.test(DirtyTrackingCollectionTest.java:56)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
java.lang.Thread.run(Thread.java:748)

لذلك ، يقوم $$_hibernate_removeDirtyFields() باستدعاء size() على مجموعة غير مهيأة. _هل يجب أن تكون؟

أنا معك أن النهج الحالي للتحسين ليس مثاليًا وأنه يجب تهيئة الحقل إلى مجموعة ثابتة ، لكنني أعتقد أن المشكلة التي تواجهها في RX قد تكون ناجمة عن شيء آخر. عندما أضبط العلم على صواب ، أرى أن المجموعة تتم تهيئتها من خلال هذا التتبع:

ربما أفتقد شيئًا ما ، لكن أليست هذه هي نفس المشكلة؟
لا يزال يستدعي size() لكن بطريقة مختلفة

انت على حق. يبدو أن المجموعات غير مسجلة على أنها كسولة مما يسبب هذه المشكلة. أنا أحقق الآن.

هنا العلاقات العامة التي يجب أن تصلح هذه المشكلات: https://github.com/hibernate/hibernate-orm/pull/3664

شكرًا beikov ، يبدو أن الاختبار يعمل باستخدام هذا الفرع

beikov ممتاز شكرا

شكرًا beikov ، يبدو أن الاختبار يعمل باستخدام هذا الفرع

DavideD هل يمكنك إعادة الاختبار الآن ، beikov قام للتو بتحديث العلاقات العامة ، دعنا نرى ما إذا كان لا يزال يعمل على حل المشكلة.

هنا PR يجب أن يصلح هذه المشكلات: hibernate / hibernate-orm # 3664

تم التأكيد ، نحتاج فقط إلى إصدار hibernate-core .

تم الإصلاح بواسطة # 463

شكرا لكم جميعا