Hibernate-reactive: उदाहरण ओआरएम 5.4.24 के साथ विफल रहता है

ओह, आप सही कह रहे हैं: @Sanne और मैं दोनों सीआई में अन्य नकली विफलताओं के कारण इसे चूक गए।

मुझे एक अनुमान है कि यह #443 से संबंधित है।

क्या यह समस्या डर्टीचेकिंग से संबंधित है?
मुझे लगता है कि समस्या इससे संबंधित है: https://github.com/hibernate/hibernate-reactive/issues/447

वैसे भी, यह ओआरएम 5.4.24 के अपडेट के बाद होता है

क्या यह समस्या डर्टीचेकिंग से संबंधित है?

खैर, मुझे लगा कि बग बैच लोडिंग से संबंधित है। हो सकता है मैं गलत हूं।

क्या यह समस्या डर्टीचेकिंग से संबंधित है?

खैर, मुझे लगा कि बग बैच लोडिंग से संबंधित है। हो सकता है मैं गलत हूं।

ओह ठीक है, ऐसा लगता है कि मैं गलत हूँ और समस्या वास्तव में कहीं और है।

मैं एक परीक्षण मामले पर काम कर रहा हूँ। उम्मीद है कि मैं जल्द ही इसकी पुष्टि कर सकूंगा।

हालांकि यह समझ में आता है क्योंकि केवल उदाहरण विफल रहता है और यह एकमात्र ऐसा स्थान है जहां हम बाइटकोड एन्हांसमेंट को सक्षम करते हैं

ठीक है अच्छा है।

इसलिए हां। बाइट कोड एन्हांसमेंट सक्षम होने पर समस्या संग्रह की गंदी जाँच है। मुझे नहीं पता कि यह पहले क्यों काम कर रहा था। शायद, ओआरएम में यह बग समस्या को छुपा रहा था और अब जब यह ठीक हो गया है तो हम इसे देखते हैं।

उफ्फ, क्या पिटा है।

OTOH, जब हमारे पास अभी तक CollectionPersister s भी नहीं है, तब भी संग्रह _matter_ की गंदी जाँच क्यों करता है?

यह है मुद्दा:

बढ़ी हुई विधि $$_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 मेरे द्वारा बनाए गए परीक्षण के अंदर एसोसिएशन का नाम है

@ डेविड डी तो क्या आपको लगता है कि यहां जो हो रहा है वह सिर्फ इतना है कि हमारे पास पारदर्शी आलसी fetch() कॉल गुम है), या यह कुछ गहरा है?

@DavidD मैंने https://github.com/hibernate/hibernate-orm/pull/3645 पर टिप्पणी की है, क्योंकि size() पर वह कॉल मुझे सही नहीं लगती। (लेकिन मैं आसानी से कुछ याद कर रहा था।)

@ डेविड डी तो क्या आपको लगता है कि यहां जो हो रहा है वह सिर्फ इतना है कि हमारे पास पारदर्शी आलसी

मुझे लगता है कि यही मुद्दा है। मैं यह देखने की कोशिश कर रहा हूं कि क्या मैं कहीं संग्रह ला सकता हूं ताकि यह पहले से ही लाया जा सके।
वैसे, अगर मैं EAGER फ़ेचिंग के लिए एसोसिएशन सेट करता हूँ तो सब कुछ काम करता है।

मैं यह देखने की कोशिश कर रहा हूं कि क्या मैं कहीं संग्रह ला सकता हूं ताकि यह पहले से ही लाया जा सके।

ठीक है, लेकिन उस पर खुद को मत मारो क्योंकि अभी भी मुझे यह गलत लगता है कि हम इसके तत्वों की जांच करने के लिए mappedBy साथ एक गैर-प्राप्त एसोसिएशन ला रहे हैं। आइए देखें कि @beikov और @Sanne का क्या कहना है।

(ओटीओएच, भले ही कोर सही काम नहीं कर रहा है _इस विशेष मामले में_, हमें अभी भी अन्य मामलों में आपके काम को ठीक करने की आवश्यकता हो सकती है।)

अतिरिक्त जानकारी के लिए, यह परीक्षण मामले वाली शाखा है (अभी भी एक कार्य प्रगति पर है): 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 क्यों है? मैंने इसे कोर में पुन: पेश करने की कोशिश की, लेकिन ऐसा नहीं हो सका क्योंकि आलसी होने पर ऐसा संग्रह कभी भी शून्य नहीं होना चाहिए।

खैर, मुझे याद है कि कहीं न कहीं थोड़ी लंबी चर्चा हुई थी। एक मुद्दा मैंने खोला जहां मैंने तर्क दिया कि यह "डबल-आलस्य" या संग्रह हाइबरनेट ओआरएम में कम से कम तर्कसंगत रूप से खराब था, और एचआर के लिए एक और भी बदतर समस्या थी, जहां लाने पारदर्शी नहीं है। हमें आपको उस पर fetch() पर कॉल करने के लिए संग्रह का संदर्भ प्राप्त करने देना होगा।

ठीक है मिल गया। तो क्या यह #374 से संबंधित हो सकता है?

और https://github.com/hibernate/hibernate-orm/pull/3558

क्या collectionsInDefaultFetchGroupEnabled हमेशा RX में सही होता है?

हम्म, अगर मैं इसे सत्य पर सेट करता हूं, तो संग्रह उत्सुकता से प्रारंभ किया जाता है।

क्या collectionsInDefaultFetchGroupEnabled हमेशा RX में सही होता है?

हाँ, यह है।

हम्म, अगर मैं इसे सत्य पर सेट करता हूं, तो संग्रह उत्सुकता से प्रारंभ किया जाता है।

उम्म्म ... सच में? वह इरादा नहीं था!

collectionsInDefaultFetchGroupEnabled को डिफ़ॉल्ट फ़ेच समूह में संग्रह प्रॉक्सी को शामिल करना चाहिए । यह वास्तव में संग्रह को ही लाने वाला नहीं है।

तो या तो मैं पूरी तरह से खराब हो गया, या जब से मैंने उस कोड को लिखा है तब से कुछ बदल गया है।

मैं आपके साथ हूं कि वृद्धि के लिए वर्तमान दृष्टिकोण आदर्श नहीं है और यह कि क्षेत्र को एक सतत संग्रह के लिए आरंभ किया जाना चाहिए, लेकिन मुझे लगता है कि आरएक्स में आपके पास जो समस्या है वह किसी और चीज के कारण हो सकती है। जब मैं ध्वज को सत्य पर सेट करता हूं, तो मुझे इस ट्रेस के माध्यम से संग्रह प्रारंभ किया जा रहा है:

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() पर कॉल कर रहा है। _क्या यह होना चाहिए?

मैं आपके साथ हूं कि वृद्धि के लिए वर्तमान दृष्टिकोण आदर्श नहीं है और यह कि क्षेत्र को एक सतत संग्रह के लिए आरंभ किया जाना चाहिए, लेकिन मुझे लगता है कि आरएक्स में आपके पास जो समस्या है वह किसी और चीज के कारण हो सकती है। जब मैं ध्वज को सत्य पर सेट करता हूं, तो मुझे इस ट्रेस के माध्यम से संग्रह प्रारंभ किया जा रहा है:

मुझे शायद कुछ याद आ रहा है, लेकिन क्या यह वही मुद्दा नहीं है?
यह अभी भी size() पर कॉल कर रहा है लेकिन एक अलग तरीके से

तुम सही हो। जाहिरा तौर पर संग्रह आलसी होने के रूप में पंजीकृत नहीं हैं जो इस समस्या का कारण बनता है। मैं अभी जांच कर रहा हूं।

यहां एक पीआर जो इन मुद्दों को ठीक करना चाहिए: https://github.com/hibernate/hibernate-orm/pull/3664

धन्यवाद @beikov , परीक्षण उस शाखा का उपयोग करके काम करता प्रतीत होता है

@beikov उत्कृष्ट, धन्यवाद

धन्यवाद @beikov , परीक्षण उस शाखा का उपयोग करके काम करता प्रतीत होता है

@DavidD क्या आप अभी @beikov ने अभी PR को अपडेट किया है, देखते हैं कि क्या यह अभी भी समस्या को ठीक करता है।

यहां एक पीआर जो इन मुद्दों को ठीक करना चाहिए: hibernate/hibernate-orm#3664

पुष्टि की गई है, हमें केवल hibernate-core रिलीज़ की आवश्यकता है।

#463 . द्वारा तय

सबको शुक्रीया