Hi all, I would like to start a discussion to know what is the general opinion about $subject, triggered by HHH- 10356. I'm also taking the opportunity to hear about some considerations I have on the configuration of the build-time plugins. * ** **- Run time* Right now it is not possible to configure runtime enhancement. The 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used to enable runtime enhancement, but unlike the build-time plugins there is no way to configure what functionalities are enabled. DefaultEnhancementContext is always used. My propose is to define a new set of properties, one for each of the features: (the names of the properties here are chosen to match the names in the build-time plugins) 'hibernate.enhance.enableLazyInitialization' 'hibernate.enhance.enableDirtyTracking' 'hibernate.enhance.enableAssociationManagement' Regarding the existing property, I think the best is to deprecate it. If it's used, show an warning message with instructions to update the configuration. * **- Build time* Since we are on the subject, I would like to hear everyone's opinion about changing the default values for each of the features in the build time plugins. These would be all disabled by default, to be consistent with runtime enhancement. Due to the nature of bytecode enhancement, developers can sometime be caught by surprise since the code they see in the IDE is not what ends up being deployed. Having to enable each of the features makes developers more aware of what to expect. It will also help to getter better bug reports. Something like 'I enabled feature X and Y start to fail' will give us clues on the possible issue. To help current users unaware of this change, a warn should be printed if a plugin runs without any feature enabled. Finally, as part of issue HHH-10354 I propose renaming the undocumented feature 'enableFieldAccessEnhancement' to 'enableExtendedEnhancement' --- the big warning around it is to keep !!! Regards, -- Luis Barreiro JBoss^® by Red Hat _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi all, I would like to start a discussion to know what is the general opinion about $subject, triggered by HHH- 10356. I'm also taking the opportunity to hear about some considerations I have on the configuration of the build-time plugins. * ** **- Run time* Right now it is not possible to configure runtime enhancement. The 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used to enable runtime enhancement, but unlike the build-time plugins there is no way to configure what functionalities are enabled. DefaultEnhancementContext is always used. My propose is to define a new set of properties, one for each of the features: (the names of the properties here are chosen to match the names in the build-time plugins) 'hibernate.enhance.enableLazyInitialization' 'hibernate.enhance.enableDirtyTracking' 'hibernate.enhance.enableAssociationManagement' Regarding the existing property, I think the best is to deprecate it. If it's used, show an warning message with instructions to update the configuration. * **- Build time* Since we are on the subject, I would like to hear everyone's opinion about changing the default values for each of the features in the build time plugins. These would be all disabled by default, to be consistent with runtime enhancement. Due to the nature of bytecode enhancement, developers can sometime be caught by surprise since the code they see in the IDE is not what ends up being deployed. Having to enable each of the features makes developers more aware of what to expect. It will also help to getter better bug reports. Something like 'I enabled feature X and Y start to fail' will give us clues on the possible issue. To help current users unaware of this change, a warn should be printed if a plugin runs without any feature enabled. Finally, as part of issue HHH-10354 I propose renaming the undocumented feature 'enableFieldAccessEnhancement' to 'enableExtendedEnhancement' --- the big warning around it is to keep !!! Regards, -- Luis Barreiro JBoss^® by Red Hat _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > Hi Luis, > thanks for this proposal, I was looking forward to see more > improvements in the area. > > Adding more properties sounds good to me, although I'd not use the > prefix "hibernate.enhance" as it sounds like it's about enhancing > Hibernate - which might be true but one could say the same with many > other features. > What about > "hibernate.bytecode_enhancer" as a prefix? > Or > "hibernate.entity_enhancer" ? > > About the build plugins: I could not find any documentation about > them, in fact I don't know which features they have. Could you > summarize those, and ideally add much needed documentation when > implementing these improvements? > It's hard to ask feedback from users about using these, as I don't > know how to run them myself ;) > Hm, there is a problem in the doc generation apparently :( For some reason this chapter is not pulled in https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

get Neo4j transaction id in OGM?

Hi Gytis, I've sent a pull request for Neo4j remote some time ago: https://github.com/hibernate/hibernate-ogm/pull/596 This is an initial prototype and it still requires some work. That said, I think you will be able to obtain the transaction id via the TransactionCoordinator: TransactionDriver driver = transactionCoordinator.getTransactionDriverControl(); Neo4jTransactionDriver neo4jDriver = (Neo4jTransactionDriver) driver; Long transactionId = driver.getTransactionId(); As Emmanuel said, this might change in the future though, and it depends what you need. Cheers, Davide On Thu, Dec 3, 2015 at 7:40 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Hey Gytis, > > Davide is the right person to talk to. We were discussing this very > subject during our face to face meeting and a few things will change. So > now is a good time to feed your needs. > > Emmanuel > > > On 30 nov. 2015, at 16:23, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > > Hi Gytis, > > > > Excellent to hear that you are looking at Neo4j. I'm not sure, Emmanuel > would be the better person to ask. > > > > Scott > > > >> On 11/26/2015 12:23 PM, HipChat wrote: > >> Gytis Trikleris > >> < > https://www.hipchat.com/people/show/2470601?utm_medium=email&utm_sour... > > > >> just sent you a 1-1 message but you're offline: > >> > >> Gytis Trikleris > >> Hey Scott! I am playing around with Neo4j as a result of your email for > >> Tom last month. The one about recovering Neo4j transactions via their > >> REST API. > >> I'm checking whether it's doable, so would like to do a prototype for > >> it. Do you know, if there is already a way to get Neo4j transaction id > >> in OGM? > >> 12:23 PM > >> zdMpSzlniIzd770 > >> > >> > >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Hm, there is a problem in the doc generation apparently :( For some > reason this chapter is not pulled in > https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/... > > Ah, because it's not in 5.0 :) That's in master for 5.1

Hi Luis, thanks for this proposal, I was looking forward to see more improvements in the area. Adding more properties sounds good to me, although I'd not use the prefix "hibernate.enhance" as it sounds like it's about enhancing Hibernate - which might be true but one could say the same with many other features. What about "hibernate.bytecode_enhancer" as a prefix? Or "hibernate.entity_enhancer" ? About the build plugins: I could not find any documentation about them, in fact I don't know which features they have. Could you summarize those, and ideally add much needed documentation when implementing these improvements? It's hard to ask feedback from users about using these, as I don't know how to run them myself ;) Thanks, Sanne On 4 December 2015 at 06:29, Luis Barreiro <lbarreiro(a)redhat.com&gt; wrote: > Hi all, > > I would like to start a discussion to know what is the general opinion > about $subject, triggered by HHH- 10356. > I'm also taking the opportunity to hear about some considerations I have > on the configuration of the build-time plugins. > * > ** > **- Run time* > > Right now it is not possible to configure runtime enhancement. The > 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used > to enable runtime enhancement, but unlike the build-time plugins there > is no way to configure what functionalities are enabled. > DefaultEnhancementContext is always used. My propose is to define a new > set of properties, one for each of the features: > (the names of the properties here are chosen to match the names in > the build-time plugins) > 'hibernate.enhance.enableLazyInitialization' > 'hibernate.enhance.enableDirtyTracking' > 'hibernate.enhance.enableAssociationManagement' > > Regarding the existing property, I think the best is to deprecate > it. If it's used, show an warning message with instructions to update > the configuration. > > * > **- Build time* > > Since we are on the subject, I would like to hear everyone's > opinion about changing the default values for each of the features in > the build time plugins. These would be all disabled by default, to be > consistent with runtime enhancement. Due to the nature of bytecode > enhancement, developers can sometime be caught by surprise since the > code they see in the IDE is not what ends up being deployed. Having to > enable each of the features makes developers more aware of what to expect. > It will also help to getter better bug reports. Something like 'I > enabled feature X and Y start to fail' will give us clues on the > possible issue. > To help current users unaware of this change, a warn should be > printed if a plugin runs without any feature enabled. > > Finally, as part of issue HHH-10354 I propose renaming the > undocumented feature 'enableFieldAccessEnhancement' to > 'enableExtendedEnhancement' --- the big warning around it is to keep !!! > > > Regards, > > -- > Luis Barreiro > JBoss^® by Red Hat > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev