From gunnar at hibernate.org Mon Sep 1 07:20:18 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 1 Sep 2014 13:20:18 +0200 Subject: [hibernate-dev] WildFly, JtaPlatform and Hibernate OGM Message-ID: Hi, Running an OGM integration test on WildFly, I noticed that we work with JBossStandAloneJtaPlatform. Shouldn't it rather be JBossAppServerJtaPlatform in this case so we make use of the transaction manager from the container? So I thought it might help to add jipijapa-hibernate4-3.jar to the OGM module, as it provides HibernatePersistenceProviderAdaptor which in turn sets the JBossAppServerJtaPlatform. This works indeed, but unfortunately HibernatePersistenceProviderAdaptor always bootstraps Hibernate ORM by calling ORM's EMF builder. What'd be the right way to solve this problem? Have a specific JipiJapa adaptor for OGM? Or could the existing one for ORM 4.3 actually be used if it invoked the configured PersistenceProvider (HibernateOgmPersistence in our case) rather than directly delegating to ORM's Bootstrap class? Thanks, --Gunnar From emmanuel at hibernate.org Tue Sep 2 11:03:12 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Sep 2014 17:03:12 +0200 Subject: [hibernate-dev] NoORM meeting Message-ID: <423B366A-C48C-4B5A-961E-AE0E476CFF45@hibernate.org> We discussed the following subjects OGM: - the state of the JTA integration with Neo4J and whether that has priority over OGM GA. - the SPI / Impl split for OGM - the WildFly JtaPlatform configuration (manual or Jipijapa) Search: - still focused on Infinispan?s performance unlocks since end of July - expect to be finished in a day of work - no progress on other aspects so far HV: - Hardy is on it to close up on the summer subjects (Java 8) and preparing conferences Meeting ended Tue Sep 2 14:57:27 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-09-02-14.03.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-09-02-14.03.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-09-02-14.03.log.html From steve at hibernate.org Tue Sep 2 14:41:38 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 2 Sep 2014 13:41:38 -0500 Subject: [hibernate-dev] Advice - cyclic event handling Message-ID: As part of the metamodel work, one of things I am working on is redesigning the old notion of a "second pass" to be more efficient. For those not familiar, this represents a piece of processing that needs to be delayed until after another piece of processing is done. For example, processing a composite identifier metadata for an entity might depend on the identifier metadata for another entity being processed first. "second pass" was essentially one big bucket. In the new design I am trying to categorize or segment these things better, so we have different buckets (one for identifier metadata completion, one for attribute Type metadata completion, etc). Not to get too involved, but essentially a bucket is a List of "watchers" for specific "happenings" (I think of them as events, but am trying to avoid that terminology for now). E.g., take the "identifier metadata completion" bucket. As we complete the binding of the identifier metadata for an entity, we fire off a notification of that happening. The watchers can then react to that notification. The implementation of this is a List of watchers, as I said, which is iterated over for each notification. So here comes the trickiness. As each watcher is finished it needs to be removed from the list of watchers. And a watcher could in turn kick off a new notification (for it completing whatever it represents). So in the initial impl I ran into ConcurrentModificationException problems. I went ahead and made it work just to move forward. But I wanted to circle back and design this "right"; so I wanted to get others involved to see if anyone had thoughts or better ideas. Here is a simple example to use as a basis for discussion: consider the entity Customer and Order. Customer has a simple identifier, whereas Order has a composite identifier made up of (1) FK to Customer and (2) a order number. We need the identifier metadata for Customer to be completely bound before we can process the identifier metadata for Order. That is the crux of the problem to be solved. Its an ordering concern. If the metadata for the Customer entity is processed first, no big deal. But of course we can't really control that (putting the onus back on the user here is fugly). So we need to account for the case where metadata for the Order entity is processed first. This kind of timing thing is the reason for second passes and these new notifications. The idea in the new design is that we would register a watcher for Order which waits for the notification that Customer identifier metadata has been finished. As the identifier for each entity is completed, that process fires off a notification of that fact. So as the identifier metadata for Customer is finished, the process fires off a notification which makes its way back to the watcher for Order. Processing can now bind the identifier metadata for Order, and in turn fire off its notification. The trouble here, in the iteration impl, is that we are still iterating over the "identifier metadata completion" notification, so there is an active iterator over the list. When performing the Order-watcher processing, since it no longer needs to watch, we would ideally remove it. Initially I had simply exposed a deregistration method that removed the watcher from the list, but that ran into the problems with CME. What I do currently instead is to expose a method on the watcher contract for the watcher to say whether its work is done, and if so use the Iterator to remove it. That works, just not sure its the best option. Another consideration is the iteration over non-interested watchers. This may be a non-issue, not sure yet. Currently watchers simply register as being interested in identifier metadata completion notifications, not notifications for completion of identifier metadata for specific entity(s). So on the con side, the List would become a Map and we'd need a key object. On the plus side we'd avoid the iteration and CME problems altogether. From smarlow at redhat.com Wed Sep 3 09:06:30 2014 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 03 Sep 2014 09:06:30 -0400 Subject: [hibernate-dev] WildFly, JtaPlatform and Hibernate OGM In-Reply-To: References: Message-ID: <54071256.3010706@redhat.com> On 09/01/2014 07:20 AM, Gunnar Morling wrote: > Hi, > > Running an OGM integration test on WildFly, I noticed that we work with > JBossStandAloneJtaPlatform. Shouldn't it rather be > JBossAppServerJtaPlatform in this case so we make use of the transaction > manager from the container? org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform sounds better. > > So I thought it might help to add jipijapa-hibernate4-3.jar to the OGM > module, as it provides HibernatePersistenceProviderAdaptor which in turn > sets the JBossAppServerJtaPlatform. This works indeed, but unfortunately > HibernatePersistenceProviderAdaptor always bootstraps Hibernate ORM by > calling ORM's EMF builder. There was a memory leak in Hibernate, see [1] [2] [3] for more details. > > What'd be the right way to solve this problem? Have a specific JipiJapa > adaptor for OGM? Or could the existing one for ORM 4.3 actually be used if > it invoked the configured PersistenceProvider (HibernateOgmPersistence in > our case) rather than directly delegating to ORM's Bootstrap class? No reason why there couldn't be a JipiJapa adaptor for OGM. One question to answer is whether there will only be one JipiJapa adapter for all versions of OGM or a different Jipi adaptor per OGM minor release (as we do for ORM currently). Currently, the JipiJapa release cycle tries to be in sync with the WildFly schedule. At the moment, Jipi is lagging behind and needs to catch up on feature development. The missing feature at the moment, is enabling 2lc clustering via Jipi callbacks, that will allow more persistence providers to cluster the 2lc (with WildFly). Currently, we only allow the very latest supported Hibernate ORM 2lc to be clustered. Scott [1] https://issues.jboss.org/browse/JIPI-13 reverted the https://issues.jboss.org/browse/JIPI-8 change due to memory leak. [2] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html [3] https://hibernate.atlassian.net/browse/HHH-8363 (ClassLoaderServiceImpl should be defined as Stoppable) [4] https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/config/Configuration.java#L55 > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From m.schipperheyn at gmail.com Wed Sep 3 11:58:30 2014 From: m.schipperheyn at gmail.com (Marc Schipperheyn) Date: Wed, 3 Sep 2014 12:58:30 -0300 Subject: [hibernate-dev] Projecting an index Message-ID: I'm wondering if would be conceivable to project a custom index based on the programmatic API when you are also using Annotations? Our use case is basically that we have a social "wall" where we retrieve "posts" which can reference related objects: other posts, user info, classifieds, events, groups, etc. In most cases, we'll reference these with a title, url, description and photo. Additionally, each object can have a specific property, such as an event having a startDate and an RSVP. We don't store this information directly in the post index because changes in them could affect a large number of posts and have undesired performance impacts We are avoiding to load stuff from the database because of the load each retrieval could generate and are basically loading as much as possible from the index. One alternative approach would be to use the index to load post ids and then load the posts as is from the database = large number of queries through lazy initialization. We went the pure index way. In order to load all this information each load of a list of posts requires some preloading and some iterations to first load the posts and then load related objects from their own indices. This kind of staggered approach offers some nice caching opportunities. But ideally, I would like to have a limited flattened index that contains all the related data for a post, but that does allow me to automatically update data in it if the underlying object changes. ideally, I would like to store in that index something like this object class id title url description photo [custom fields] I'm curious if something like this would be achievable with HSearch? From sanne at hibernate.org Sun Sep 7 09:04:57 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 7 Sep 2014 14:04:57 +0100 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org Message-ID: Hi all, I've installed latest preview builds of: - JDK 9 b28 - JDK 8u40 b04 Java 9 is new in our builds, so some considerations: - The JVM option MaxPermSize, which was deprecated in Java8, is no longer accepted and will fail bootstrap. Either you remove it from your build path or enable -XX:+IgnoreUnrecognizedVMOptions - asciidoctor-maven-plugin plugin fails: I'll disable it for now but it would be great if someone could have a look at it, if it's a JVM bug we should report it, and otherwise fixing the plugin would be nice. On Java 8, a warning: I've not simply added this beta, but it replaces the current one we had setup. I realize this is a rather aggressive move, but keep in mind the current one wasn't a stable release but an early preview as well. I guess we might want to split this into a "JDK 8" and a "JDK 8-preview" ? But even our current JDK8 builds are still largely failing, so I'd rather see some love on that first, then we can move on into multiple builds. I would love some help on: - the animal-sniffer is still broken on Java 8, see what can be done or let's discuss alternatives - Some ORM tests are failing on Java8 - Define JDK 9 test builds for more projects: http://ci.hibernate.org/view/JDK9/ Cheers, Sanne From emmanuel at hibernate.org Mon Sep 8 07:25:40 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 8 Sep 2014 13:25:40 +0200 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: References: Message-ID: <20140908112540.GA13087@hibernate.org> On Sun 2014-09-07 14:04, Sanne Grinovero wrote: > - asciidoctor-maven-plugin plugin fails: I'll disable it for now but > it would be great if someone could have a look at it, if it's a JVM > bug we should report it, and otherwise fixing the plugin would be > nice. Can you point me to a URL showing the failure? I can try and contact the relevant persons. From sanne at hibernate.org Mon Sep 8 07:31:35 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Sep 2014 12:31:35 +0100 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: <20140908112540.GA13087@hibernate.org> References: <20140908112540.GA13087@hibernate.org> Message-ID: On 8 September 2014 12:25, Emmanuel Bernard wrote: > On Sun 2014-09-07 14:04, Sanne Grinovero wrote: >> - asciidoctor-maven-plugin plugin fails: I'll disable it for now but >> it would be great if someone could have a look at it, if it's a JVM >> bug we should report it, and otherwise fixing the plugin would be >> nice. > > Can you point me to a URL showing the failure? I can try and contact the > relevant persons. I did debug it, and found that Asciidoctor fails to initialize JRuby: the JRuby engine checks which JVM it's being run on to generate appropriate opcodes.. and refuses to start on JDK9. I guess that's fair enough, so the question would be if there is an easy way to disable the asciidoctor-maven-plugin from an environment switch, or if we need to mess with Maven profiles. From emmanuel at hibernate.org Mon Sep 8 07:57:37 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 8 Sep 2014 13:57:37 +0200 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: References: <20140908112540.GA13087@hibernate.org> Message-ID: <20140908115737.GD13087@hibernate.org> I've push the information to the Asciidoctor folks. I don't know about any switch though. I guess we do have a way to enable or disable doc generation but because of various preferences between project leads, nothing is consistent. On Mon 2014-09-08 12:31, Sanne Grinovero wrote: > On 8 September 2014 12:25, Emmanuel Bernard wrote: > > On Sun 2014-09-07 14:04, Sanne Grinovero wrote: > >> - asciidoctor-maven-plugin plugin fails: I'll disable it for now but > >> it would be great if someone could have a look at it, if it's a JVM > >> bug we should report it, and otherwise fixing the plugin would be > >> nice. > > > > Can you point me to a URL showing the failure? I can try and contact the > > relevant persons. > > I did debug it, and found that Asciidoctor fails to initialize JRuby: > the JRuby engine checks which JVM it's being run on to generate > appropriate opcodes.. and refuses to start on JDK9. > I guess that's fair enough, so the question would be if there is an > easy way to disable the asciidoctor-maven-plugin from an environment > switch, or if we need to mess with Maven profiles. From sanne at hibernate.org Mon Sep 8 08:06:16 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Sep 2014 13:06:16 +0100 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: <20140908115737.GD13087@hibernate.org> References: <20140908112540.GA13087@hibernate.org> <20140908115737.GD13087@hibernate.org> Message-ID: Thanks! I have no strong preference, just preferring to keep it on by default as it generally runs quickly enough; but YMMV if it's slow for someone and impairs quick experimentation I'd be fine to disable it. But obviously we need a switch to turn it off for such cases as the JDK not being compatible. Sanne On 8 September 2014 12:57, Emmanuel Bernard wrote: > I've push the information to the Asciidoctor folks. > I don't know about any switch though. I guess we do have a way to enable > or disable doc generation but because of various preferences between > project leads, nothing is consistent. > > On Mon 2014-09-08 12:31, Sanne Grinovero wrote: >> On 8 September 2014 12:25, Emmanuel Bernard wrote: >> > On Sun 2014-09-07 14:04, Sanne Grinovero wrote: >> >> - asciidoctor-maven-plugin plugin fails: I'll disable it for now but >> >> it would be great if someone could have a look at it, if it's a JVM >> >> bug we should report it, and otherwise fixing the plugin would be >> >> nice. >> > >> > Can you point me to a URL showing the failure? I can try and contact the >> > relevant persons. >> >> I did debug it, and found that Asciidoctor fails to initialize JRuby: >> the JRuby engine checks which JVM it's being run on to generate >> appropriate opcodes.. and refuses to start on JDK9. >> I guess that's fair enough, so the question would be if there is an >> easy way to disable the asciidoctor-maven-plugin from an environment >> switch, or if we need to mess with Maven profiles. From hardy at hibernate.org Mon Sep 8 10:15:41 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 8 Sep 2014 16:15:41 +0200 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: References: <20140908112540.GA13087@hibernate.org> <20140908115737.GD13087@hibernate.org> Message-ID: <20140908141540.GA43072@Sarmakand-2.local> On Mon, Sep 08, 2014 at 01:06:16PM +0100, Sanne Grinovero wrote: > I have no strong preference, just preferring to keep it on by default > as it generally runs quickly enough; +1 for keeping things running per default (and it is a strong preference ;-)) > But obviously we need a switch to turn it off for such cases as the > JDK not being compatible. Do we right now? Can we not just wait a bit to things how things are shaping up? I get the point of being pro-active, but do we need a Java 9 build right now? I'll let the asciisoc and JRuby guys chew a little bit on this and see what they come up with. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20140908/be324121/attachment.bin From emmanuel at hibernate.org Mon Sep 8 10:58:53 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 8 Sep 2014 16:58:53 +0200 Subject: [hibernate-dev] Advice - cyclic event handling In-Reply-To: References: Message-ID: <20140908145853.GE13087@hibernate.org> Throwing off some ideas. Have you thought about an entity A whose composed id is made of the id of two different entities B and C. A would enlist to B and C completion and would need to record when it receives the first event and process everything when the second event arrives? A way around your problem could be to use index lookups instead of iterators to process the watch list. That way you can set a specific index to null when it is processed without affecting the subsequent indexes nor raise a CME. That would be close to a ring buffer implementation I suppose. Emmanuel On Tue 2014-09-02 13:41, Steve Ebersole wrote: > As part of the metamodel work, one of things I am working on is redesigning > the old notion of a "second pass" to be more efficient. For those not > familiar, this represents a piece of processing that needs to be delayed > until after another piece of processing is done. For example, processing a > composite identifier metadata for an entity might depend on the identifier > metadata for another entity being processed first. > > "second pass" was essentially one big bucket. In the new design I am > trying to categorize or segment these things better, so we have different > buckets (one for identifier metadata completion, one for attribute Type > metadata completion, etc). > > Not to get too involved, but essentially a bucket is a List of "watchers" > for specific "happenings" (I think of them as events, but am trying to > avoid that terminology for now). E.g., take the "identifier metadata > completion" bucket. As we complete the binding of the identifier metadata > for an entity, we fire off a notification of that happening. The watchers > can then react to that notification. > > The implementation of this is a List of watchers, as I said, which is > iterated over for each notification. So here comes the trickiness. As > each watcher is finished it needs to be removed from the list of watchers. > And a watcher could in turn kick off a new notification (for it completing > whatever it represents). So in the initial impl I ran into > ConcurrentModificationException problems. > > I went ahead and made it work just to move forward. But I wanted to circle > back and design this "right"; so I wanted to get others involved to see if > anyone had thoughts or better ideas. > > Here is a simple example to use as a basis for discussion: consider the > entity Customer and Order. Customer has a simple identifier, whereas Order > has a composite identifier made up of (1) FK to Customer and (2) a order > number. We need the identifier metadata for Customer to be completely > bound before we can process the identifier metadata for Order. That is the > crux of the problem to be solved. Its an ordering concern. If the > metadata for the Customer entity is processed first, no big deal. But of > course we can't really control that (putting the onus back on the user here > is fugly). So we need to account for the case where metadata for the Order > entity is processed first. This kind of timing thing is the reason for > second passes and these new notifications. The idea in the new design is > that we would register a watcher for Order which waits for the notification > that Customer identifier metadata has been finished. As the identifier for > each entity is completed, that process fires off a notification of that > fact. So as the identifier metadata for Customer is finished, the process > fires off a notification which makes its way back to the watcher for Order. > Processing can now bind the identifier metadata for Order, and in turn > fire off its notification. > > The trouble here, in the iteration impl, is that we are still iterating > over the "identifier metadata completion" notification, so there is an > active iterator over the list. When performing the Order-watcher > processing, since it no longer needs to watch, we would ideally remove it. > Initially I had simply exposed a deregistration method that removed the > watcher from the list, but that ran into the problems with CME. What I do > currently instead is to expose a method on the watcher contract for the > watcher to say whether its work is done, and if so use the Iterator to > remove it. That works, just not sure its the best option. > > Another consideration is the iteration over non-interested watchers. This > may be a non-issue, not sure yet. Currently watchers simply register as > being interested in identifier metadata completion notifications, not > notifications for completion of identifier metadata for specific entity(s). > So on the con side, the List would become a Map and we'd need a key > object. On the plus side we'd avoid the iteration and CME problems > altogether. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Sep 8 17:59:23 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 8 Sep 2014 16:59:23 -0500 Subject: [hibernate-dev] Advice - cyclic event handling In-Reply-To: <20140908145853.GE13087@hibernate.org> References: <20140908145853.GE13087@hibernate.org> Message-ID: On Sep 8, 2014 9:59 AM, "Emmanuel Bernard" wrote: > > Throwing off some ideas. > > Have you thought about an entity A whose composed id is made of the id of > two different entities B and C. > A would enlist to B and C completion and would need to record when it > receives the first event and process everything when the second event > arrives? Yes, the code already accounts for this essentially in the exact way you describe. > A way around your problem could be to use index lookups instead of > iterators to process the watch list. That way you can set a specific > index to null when it is processed without affecting the subsequent > indexes nor raise a CME. That would be close to a ring buffer > implementation I suppose. Right. Depending on what you mean by indexed, this is what I mentioned in regards to regsitering the listeners keyed by the entity(s) they are interested in (given the id case). > > Emmanuel > > On Tue 2014-09-02 13:41, Steve Ebersole wrote: > > As part of the metamodel work, one of things I am working on is redesigning > > the old notion of a "second pass" to be more efficient. For those not > > familiar, this represents a piece of processing that needs to be delayed > > until after another piece of processing is done. For example, processing a > > composite identifier metadata for an entity might depend on the identifier > > metadata for another entity being processed first. > > > > "second pass" was essentially one big bucket. In the new design I am > > trying to categorize or segment these things better, so we have different > > buckets (one for identifier metadata completion, one for attribute Type > > metadata completion, etc). > > > > Not to get too involved, but essentially a bucket is a List of "watchers" > > for specific "happenings" (I think of them as events, but am trying to > > avoid that terminology for now). E.g., take the "identifier metadata > > completion" bucket. As we complete the binding of the identifier metadata > > for an entity, we fire off a notification of that happening. The watchers > > can then react to that notification. > > > > The implementation of this is a List of watchers, as I said, which is > > iterated over for each notification. So here comes the trickiness. As > > each watcher is finished it needs to be removed from the list of watchers. > > And a watcher could in turn kick off a new notification (for it completing > > whatever it represents). So in the initial impl I ran into > > ConcurrentModificationException problems. > > > > I went ahead and made it work just to move forward. But I wanted to circle > > back and design this "right"; so I wanted to get others involved to see if > > anyone had thoughts or better ideas. > > > > Here is a simple example to use as a basis for discussion: consider the > > entity Customer and Order. Customer has a simple identifier, whereas Order > > has a composite identifier made up of (1) FK to Customer and (2) a order > > number. We need the identifier metadata for Customer to be completely > > bound before we can process the identifier metadata for Order. That is the > > crux of the problem to be solved. Its an ordering concern. If the > > metadata for the Customer entity is processed first, no big deal. But of > > course we can't really control that (putting the onus back on the user here > > is fugly). So we need to account for the case where metadata for the Order > > entity is processed first. This kind of timing thing is the reason for > > second passes and these new notifications. The idea in the new design is > > that we would register a watcher for Order which waits for the notification > > that Customer identifier metadata has been finished. As the identifier for > > each entity is completed, that process fires off a notification of that > > fact. So as the identifier metadata for Customer is finished, the process > > fires off a notification which makes its way back to the watcher for Order. > > Processing can now bind the identifier metadata for Order, and in turn > > fire off its notification. > > > > The trouble here, in the iteration impl, is that we are still iterating > > over the "identifier metadata completion" notification, so there is an > > active iterator over the list. When performing the Order-watcher > > processing, since it no longer needs to watch, we would ideally remove it. > > Initially I had simply exposed a deregistration method that removed the > > watcher from the list, but that ran into the problems with CME. What I do > > currently instead is to expose a method on the watcher contract for the > > watcher to say whether its work is done, and if so use the Iterator to > > remove it. That works, just not sure its the best option. > > > > Another consideration is the iteration over non-interested watchers. This > > may be a non-issue, not sure yet. Currently watchers simply register as > > being interested in identifier metadata completion notifications, not > > notifications for completion of identifier metadata for specific entity(s). > > So on the con side, the List would become a Map and we'd need a key > > object. On the plus side we'd avoid the iteration and CME problems > > altogether. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Sep 8 18:57:08 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Sep 2014 23:57:08 +0100 Subject: [hibernate-dev] Tests on JDK 9, and other updates on ci.hibernate.org In-Reply-To: <20140908141540.GA43072@Sarmakand-2.local> References: <20140908112540.GA13087@hibernate.org> <20140908115737.GD13087@hibernate.org> <20140908141540.GA43072@Sarmakand-2.local> Message-ID: On 8 September 2014 15:15, Hardy Ferentschik wrote: > On Mon, Sep 08, 2014 at 01:06:16PM +0100, Sanne Grinovero wrote: > >> I have no strong preference, just preferring to keep it on by default >> as it generally runs quickly enough; > > +1 for keeping things running per default (and it is a strong preference ;-)) > >> But obviously we need a switch to turn it off for such cases as the >> JDK not being compatible. > > Do we right now? Can we not just wait a bit to things how things are shaping up? > I get the point of being pro-active, but do we need a Java 9 build right now? > I'll let the asciisoc and JRuby guys chew a little bit on this and see what > they come up with. "Right now" can be flexible of course, but the JDK will come sooner than usual. Having these tasks running doesn't necessarily imply that our stuff will work fine but it means we'll have the knowledge to be able to make informed decisions at lowest overhead (the earlier the better). I'd like us to be pro-active in terms of "our stuff will work on Java9" but I don't want to spend cycles on debugging stuff on behalf of asciidoc or JRuby to work on JDK9 too, so realistically we should disable these and let other deal with it at their own pace. Not least, we're engaged in a promise to the OpenJDK team to test these builds, in exchange we get full attention to bug reports: - https://wiki.openjdk.java.net/display/Adoption/Quality+Out+Reach Sanne From jlesinge at gmail.com Tue Sep 9 04:33:09 2014 From: jlesinge at gmail.com (John Worrell) Date: Tue, 9 Sep 2014 09:33:09 +0100 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: <20140822162544.GM8223@hibernate.org> References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi Emmanuel & Gunnar, Many thanks for your detailed responses - and nice to chat with Gunnar a week or so back. Again I have to apologise for radio silence - my day job suddenly ate all my waking functional time - so progress has been very slow. I'm getting deeper into the code now, and starting a POC... which is leading me to some more detailed questions. Basically, what I am doing is to run the examples and to look at things that seem to be missing, and toi understand the data that is being passed around in the various options classes, so I can make a more informed implementation The key question in my mind at the moment is that of the relationship between the base Hibernate Dialect class and the GridDialect interface - I look at the OgmTableGenerator which is attempting to access a CF / table that is not yet created - I figured I understand what was happening here, and make appropriate extensions / fixes first. So, currently fighting my way through generating the sequence tables, and wondering why OgmSequnceGenerator wraps OgmtableGenerator. Cheers, John On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard wrote: > On Thu 2014-08-07 9:10, John Worrell wrote: > > Hi Emmanuel et al., > > > > My apologies for the log radio silence. I've taken a look at the > code-base > > on Jon Halliday's repo, and have set up a nick on freenode - #jlesinge. > > No worries I was on holidays. > And you email was the few lucky ones that I had to delay as it required > thinking ;) > > > > > On the time-series question I was wondering how you envisaged the data > > stored: I tend to think of a single row under an primary key with an > > object-instance per column. Now what we have typically done (generally > the > > data has been immutable) is to store the data serialized as a blob (JSON > or > > XML), but I understand you do not favour this approach. With this sort of > > model I imagine the collection is then all the objects stored in the row, > > and the challenge is to page through the objects in the row. > > Actually it is one of the valid strategies. > If I understand you well, you want to create: > > - one row per time series generating object (say a thermometer) > - the column names of that row would be a timestamp of time at bay > - the value would be a JSON structure containing the data at bay for > that specific time. > > That is one of the valid approach. But I think we need to support > several: > > - simple column if the data is literally a single element (temperature) > - JSON structure for more complex data per time event > - key pointing to the detailed data somewhere else in the cluster > > The latest would be done in two phases, you load all the keys you are > interested in matching your time range and then do a multiget of sort to > load the data. > > It seems datastax tends to recommend 1 or 2 (denormalization FTW). > > I don't know but there is also the notion of super column which is a > grouping of columns that might also address our composite problem > assuming they can be used for dynamic column families. > > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra > > http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ > http://www.datastax.com/docs/1.0/ddl/column_family > > > > > An approach we have often taken is to create multiple copies of data in > > different (obviously works well only for immutable objects) or better to > > Yes, that is a feature that I would like OGM to automate for the user. > It declaratively defines the denormalization approaches he wants and the > engine does the persistence. > Next the query engine uses that knowledge to find the best path (or only > possible path in the case of Cassandra :) ) > > > create a table of keys to a main table where in either approach the > > row-keys are effectively a foreign-key and there is column per object > > associated through the foreign-key. Another approach though might be to > use > > a column with type list (or set, or map) to contain keys to the > associated > > objects - this would be a little like the extensions Oracle have for > > mapping 1-* associations, though with the caveat that a column of > > collection type may only contain 64k elements. I wondered if some though > > had been given to this strategy (which I must admit I have not yet used > > myself). > > I am not aware of that approach. > > > > > It seems very likely that different mapping strategies should be > > specifiable, but then I have still to understand how these might fit with > > treiid. > > Forget Teiid for now. We will likely start with the HQL->Walker and do > our own proto query engine before layering Teiid. > > > > > Can I ask about assumptions: is it fair to assume that for Cassandra, OGM > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This would > > certainly make life simpler. > > Yes that's fine. > > > > > An issue I don't see addressed is the choice of consistency-level (read > or > > write) and I wondered if there was a plan for this? Assumptions can be > made > > on a per table basis, but, certainly for ad hoc queries, it is important > > think to have the flexibility to specify on a per-query basis. > > That's planned. We have an option system that allow for entity / > property overriding of a global setting. While not implemented, we will > also have the ability to override setting per session / query. > That was the plan all along. > > > > > Those are my thoughts so far... I'll see about doing a POC of some of > what > > I have described above > > Thanks :) > > > > > Cheers, > > > > John > > > > > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell > wrote: > > > > > Hi Emmanuel, > > > > > > I'll take a look at what is there, and I'll get up and running on IRC. > > > > > > I'll particularly look at the time-series issue - non-trivial I think. > > > > > > Cheers, > > > > > > John > > > > > > > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < > emmanuel at hibernate.org> > > > wrote: > > > > > >> Hi John, > > >> > > >> I thought I had replied to you on Friday but apparently the email > never > > >> went through :/ > > >> > > >> That is good news :) > > >> Jonathan worked on a Cassandra prototype but had to drop due to other > > >> duties. He pushed everything at > > >> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra > > >> > > >> Have a look at what he has done and come ask any question to Gunnar, > > >> Davide or me. There are a bunch of moving pieces. We are mostly on > > >> freenode?s #hibernate-dev ( you need a freenode login > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic to > IRC, > > >> let me know and we will find alternatives. > > >> > > >> The most interesting challenge will be to see how we can map time > series > > >> into a collection and make sure we let the user decide how much he > wants to > > >> load. > > >> > > >> Emmanuel > > >> > > >> On 16 Jul 2014, at 13:17, John Worrell wrote: > > >> > > >> > Hi, > > >> > > > >> > I'm interested in contributing to the Cassandra module of > Hibernate-OGM > > >> - > > >> > what would be the baest way to go about this? > > >> > > > >> > Thanks, > > >> > > > >> > John > > >> > _______________________________________________ > > >> > hibernate-dev mailing list > > >> > hibernate-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > >> > > > > From gunnar at hibernate.org Tue Sep 9 04:59:02 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 9 Sep 2014 10:59:02 +0200 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi John, 2014-09-09 10:33 GMT+02:00 John Worrell : > Hi Emmanuel & Gunnar, > > Many thanks for your detailed responses - and nice to chat with Gunnar a > week or so back. Again I have to apologise for radio silence - my day job > suddenly ate all my waking functional time - so progress has been very > slow. > No worries, we are very glad about your help. I'm getting deeper into the code now, and starting a POC... which is > leading me to some more detailed questions. Basically, what I am doing is > to run the examples and to look at things that seem to be missing, and toi > understand the data that is being passed around in the various options > classes, so I can make a more informed implementation > Sounds very reasonable. I also can recommend to take a look at the MongoDB dialect and the persistent representations it creates in the datastore as it can comfortably be browsed e.g. using the mongo command line client. That's how I got to understand many things of the interaction between engine and dialects. If you have any ideas where the dialect SPI documentation can be improved to facilitate an easier understanding of how pieces work together, let me know. The key question in my mind at the moment is that of the relationship > between the base Hibernate Dialect class and the GridDialect interface OGM has its own pseudo implementation of ORM's Dialect contract, OgmDialect, but this should hardly ever play a role during OGM development. OGM's main contract towards dialects is GridDialect. The reason for exposing GridDialect on the pseudo OgmDialect is that it is our backdoor to make GridDialect available to PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to inject the GridDialect in a more straight-forward way due to some limitations in the way we integrate with the ORM engine. > - I > look at the OgmTableGenerator which is attempting to access a CF / table > that is not yet created - I figured I understand what was happening here, > and make appropriate extensions / fixes first. So, currently fighting my > way through generating the sequence tables, and wondering why > OgmSequnceGenerator wraps OgmtableGenerator. > Just to be sure, are you looking at the latest master? There have been some changes around these generator classes recently, they are in a much cleaner state than they used to be. The reason for the wrapping is that when using the SEQUENCE strategy in cases where the store actually does not natively support sequences, we fall back to TABLE. Currently we only support a "native" SEQUENCE strategy for Neo4j which allows to map sequences as nodes in a reasonable manner, whereas all the other dialects use the table fallback. GridDialect#supportsSequences() is evaluated to find out whether the delegation needs to be done or not. You also could take a look at Neo4jSequenceGenerator which creates the sequence nodes in the datastore based on the registered PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose these types on the dialect SPI, I'm looking into ways for allowing the distinction of the two in a more abstract way, mainly based on IdSourceKeyMetadata. Hope that helps, I'll be very happy to answer any follow-up questions. Thanks again for your help with the Cassandra dialect, I'm looking forward to this dialect very much! > > Cheers, > > John > --Gunnar > > > On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard > wrote: > > > On Thu 2014-08-07 9:10, John Worrell wrote: > > > Hi Emmanuel et al., > > > > > > My apologies for the log radio silence. I've taken a look at the > > code-base > > > on Jon Halliday's repo, and have set up a nick on freenode - #jlesinge. > > > > No worries I was on holidays. > > And you email was the few lucky ones that I had to delay as it required > > thinking ;) > > > > > > > > On the time-series question I was wondering how you envisaged the data > > > stored: I tend to think of a single row under an primary key with an > > > object-instance per column. Now what we have typically done (generally > > the > > > data has been immutable) is to store the data serialized as a blob > (JSON > > or > > > XML), but I understand you do not favour this approach. With this sort > of > > > model I imagine the collection is then all the objects stored in the > row, > > > and the challenge is to page through the objects in the row. > > > > Actually it is one of the valid strategies. > > If I understand you well, you want to create: > > > > - one row per time series generating object (say a thermometer) > > - the column names of that row would be a timestamp of time at bay > > - the value would be a JSON structure containing the data at bay for > > that specific time. > > > > That is one of the valid approach. But I think we need to support > > several: > > > > - simple column if the data is literally a single element (temperature) > > - JSON structure for more complex data per time event > > - key pointing to the detailed data somewhere else in the cluster > > > > The latest would be done in two phases, you load all the keys you are > > interested in matching your time range and then do a multiget of sort to > > load the data. > > > > It seems datastax tends to recommend 1 or 2 (denormalization FTW). > > > > I don't know but there is also the notion of super column which is a > > grouping of columns that might also address our composite problem > > assuming they can be used for dynamic column families. > > > > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra > > > > > http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ > > http://www.datastax.com/docs/1.0/ddl/column_family > > > > > > > > An approach we have often taken is to create multiple copies of data in > > > different (obviously works well only for immutable objects) or better > to > > > > Yes, that is a feature that I would like OGM to automate for the user. > > It declaratively defines the denormalization approaches he wants and the > > engine does the persistence. > > Next the query engine uses that knowledge to find the best path (or only > > possible path in the case of Cassandra :) ) > > > > > create a table of keys to a main table where in either approach the > > > row-keys are effectively a foreign-key and there is column per object > > > associated through the foreign-key. Another approach though might be to > > use > > > a column with type list (or set, or map) to contain keys to the > > associated > > > objects - this would be a little like the extensions Oracle have for > > > mapping 1-* associations, though with the caveat that a column of > > > collection type may only contain 64k elements. I wondered if some > though > > > had been given to this strategy (which I must admit I have not yet used > > > myself). > > > > I am not aware of that approach. > > > > > > > > It seems very likely that different mapping strategies should be > > > specifiable, but then I have still to understand how these might fit > with > > > treiid. > > > > Forget Teiid for now. We will likely start with the HQL->Walker and do > > our own proto query engine before layering Teiid. > > > > > > > > Can I ask about assumptions: is it fair to assume that for Cassandra, > OGM > > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This > would > > > certainly make life simpler. > > > > Yes that's fine. > > > > > > > > An issue I don't see addressed is the choice of consistency-level (read > > or > > > write) and I wondered if there was a plan for this? Assumptions can be > > made > > > on a per table basis, but, certainly for ad hoc queries, it is > important > > > think to have the flexibility to specify on a per-query basis. > > > > That's planned. We have an option system that allow for entity / > > property overriding of a global setting. While not implemented, we will > > also have the ability to override setting per session / query. > > That was the plan all along. > > > > > > > > Those are my thoughts so far... I'll see about doing a POC of some of > > what > > > I have described above > > > > Thanks :) > > > > > > > > Cheers, > > > > > > John > > > > > > > > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell > > wrote: > > > > > > > Hi Emmanuel, > > > > > > > > I'll take a look at what is there, and I'll get up and running on > IRC. > > > > > > > > I'll particularly look at the time-series issue - non-trivial I > think. > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > > > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < > > emmanuel at hibernate.org> > > > > wrote: > > > > > > > >> Hi John, > > > >> > > > >> I thought I had replied to you on Friday but apparently the email > > never > > > >> went through :/ > > > >> > > > >> That is good news :) > > > >> Jonathan worked on a Cassandra prototype but had to drop due to > other > > > >> duties. He pushed everything at > > > >> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra > > > >> > > > >> Have a look at what he has done and come ask any question to Gunnar, > > > >> Davide or me. There are a bunch of moving pieces. We are mostly on > > > >> freenode?s #hibernate-dev ( you need a freenode login > > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic to > > IRC, > > > >> let me know and we will find alternatives. > > > >> > > > >> The most interesting challenge will be to see how we can map time > > series > > > >> into a collection and make sure we let the user decide how much he > > wants to > > > >> load. > > > >> > > > >> Emmanuel > > > >> > > > >> On 16 Jul 2014, at 13:17, John Worrell wrote: > > > >> > > > >> > Hi, > > > >> > > > > >> > I'm interested in contributing to the Cassandra module of > > Hibernate-OGM > > > >> - > > > >> > what would be the baest way to go about this? > > > >> > > > > >> > Thanks, > > > >> > > > > >> > John > > > >> > _______________________________________________ > > > >> > hibernate-dev mailing list > > > >> > hibernate-dev at lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > >> > > > >> > > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From jlesinge at gmail.com Tue Sep 9 05:08:25 2014 From: jlesinge at gmail.com (John Worrell) Date: Tue, 9 Sep 2014 10:08:25 +0100 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi Gunnar, Many thanks for the reply - I'll yank down the master... assume it is merged back to the Jon Halliday fork otherwise I'll need to mess about a bit. Also had some issues with getting connected to C*, understandable, but also wrt adding tags for the Dog / Breed classes in the persistence.xml file. not sure whether that is intended to be needed. Cheers, John On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling wrote: > Hi John, > > 2014-09-09 10:33 GMT+02:00 John Worrell : > >> Hi Emmanuel & Gunnar, >> >> Many thanks for your detailed responses - and nice to chat with Gunnar a >> week or so back. Again I have to apologise for radio silence - my day job >> suddenly ate all my waking functional time - so progress has been very >> slow. >> > > No worries, we are very glad about your help. > > I'm getting deeper into the code now, and starting a POC... which is >> leading me to some more detailed questions. Basically, what I am doing is >> to run the examples and to look at things that seem to be missing, and toi >> understand the data that is being passed around in the various options >> classes, so I can make a more informed implementation >> > > Sounds very reasonable. I also can recommend to take a look at the MongoDB > dialect and the persistent representations it creates in the datastore as > it can comfortably be browsed e.g. using the mongo command line client. > That's how I got to understand many things of the interaction between > engine and dialects. > > If you have any ideas where the dialect SPI documentation can be improved > to facilitate an easier understanding of how pieces work together, let me > know. > > The key question in my mind at the moment is that of the relationship >> between the base Hibernate Dialect class and the GridDialect interface > > > OGM has its own pseudo implementation of ORM's Dialect contract, > OgmDialect, but this should hardly ever play a role during OGM development. > OGM's main contract towards dialects is GridDialect. > > The reason for exposing GridDialect on the pseudo OgmDialect is that it is > our backdoor to make GridDialect available to > PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to > inject the GridDialect in a more straight-forward way due to some > limitations in the way we integrate with the ORM engine. > > >> - I >> look at the OgmTableGenerator which is attempting to access a CF / table >> that is not yet created - I figured I understand what was happening here, >> and make appropriate extensions / fixes first. So, currently fighting my >> way through generating the sequence tables, and wondering why >> OgmSequnceGenerator wraps OgmtableGenerator. >> > > Just to be sure, are you looking at the latest master? There have been > some changes around these generator classes recently, they are in a much > cleaner state than they used to be. > > The reason for the wrapping is that when using the SEQUENCE strategy in > cases where the store actually does not natively support sequences, we fall > back to TABLE. Currently we only support a "native" SEQUENCE strategy for > Neo4j which allows to map sequences as nodes in a reasonable manner, > whereas all the other dialects use the table fallback. > GridDialect#supportsSequences() is evaluated to find out whether the > delegation needs to be done or not. > > You also could take a look at Neo4jSequenceGenerator which creates the > sequence nodes in the datastore based on the registered > PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof > for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose > these types on the dialect SPI, I'm looking into ways for allowing the > distinction of the two in a more abstract way, mainly based on > IdSourceKeyMetadata. > > Hope that helps, I'll be very happy to answer any follow-up questions. > Thanks again for your help with the Cassandra dialect, I'm looking forward > to this dialect very much! > > >> >> Cheers, >> >> John >> > > --Gunnar > > >> >> >> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard > > >> wrote: >> >> > On Thu 2014-08-07 9:10, John Worrell wrote: >> > > Hi Emmanuel et al., >> > > >> > > My apologies for the log radio silence. I've taken a look at the >> > code-base >> > > on Jon Halliday's repo, and have set up a nick on freenode - >> #jlesinge. >> > >> > No worries I was on holidays. >> > And you email was the few lucky ones that I had to delay as it required >> > thinking ;) >> > >> > > >> > > On the time-series question I was wondering how you envisaged the data >> > > stored: I tend to think of a single row under an primary key with an >> > > object-instance per column. Now what we have typically done (generally >> > the >> > > data has been immutable) is to store the data serialized as a blob >> (JSON >> > or >> > > XML), but I understand you do not favour this approach. With this >> sort of >> > > model I imagine the collection is then all the objects stored in the >> row, >> > > and the challenge is to page through the objects in the row. >> > >> > Actually it is one of the valid strategies. >> > If I understand you well, you want to create: >> > >> > - one row per time series generating object (say a thermometer) >> > - the column names of that row would be a timestamp of time at bay >> > - the value would be a JSON structure containing the data at bay for >> > that specific time. >> > >> > That is one of the valid approach. But I think we need to support >> > several: >> > >> > - simple column if the data is literally a single element (temperature) >> > - JSON structure for more complex data per time event >> > - key pointing to the detailed data somewhere else in the cluster >> > >> > The latest would be done in two phases, you load all the keys you are >> > interested in matching your time range and then do a multiget of sort to >> > load the data. >> > >> > It seems datastax tends to recommend 1 or 2 (denormalization FTW). >> > >> > I don't know but there is also the notion of super column which is a >> > grouping of columns that might also address our composite problem >> > assuming they can be used for dynamic column families. >> > >> > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra >> > >> > >> http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ >> > http://www.datastax.com/docs/1.0/ddl/column_family >> > >> > > >> > > An approach we have often taken is to create multiple copies of data >> in >> > > different (obviously works well only for immutable objects) or better >> to >> > >> > Yes, that is a feature that I would like OGM to automate for the user. >> > It declaratively defines the denormalization approaches he wants and the >> > engine does the persistence. >> > Next the query engine uses that knowledge to find the best path (or only >> > possible path in the case of Cassandra :) ) >> > >> > > create a table of keys to a main table where in either approach the >> > > row-keys are effectively a foreign-key and there is column per object >> > > associated through the foreign-key. Another approach though might be >> to >> > use >> > > a column with type list (or set, or map) to contain keys to the >> > associated >> > > objects - this would be a little like the extensions Oracle have for >> > > mapping 1-* associations, though with the caveat that a column of >> > > collection type may only contain 64k elements. I wondered if some >> though >> > > had been given to this strategy (which I must admit I have not yet >> used >> > > myself). >> > >> > I am not aware of that approach. >> > >> > > >> > > It seems very likely that different mapping strategies should be >> > > specifiable, but then I have still to understand how these might fit >> with >> > > treiid. >> > >> > Forget Teiid for now. We will likely start with the HQL->Walker and do >> > our own proto query engine before layering Teiid. >> > >> > > >> > > Can I ask about assumptions: is it fair to assume that for Cassandra, >> OGM >> > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This >> would >> > > certainly make life simpler. >> > >> > Yes that's fine. >> > >> > > >> > > An issue I don't see addressed is the choice of consistency-level >> (read >> > or >> > > write) and I wondered if there was a plan for this? Assumptions can be >> > made >> > > on a per table basis, but, certainly for ad hoc queries, it is >> important >> > > think to have the flexibility to specify on a per-query basis. >> > >> > That's planned. We have an option system that allow for entity / >> > property overriding of a global setting. While not implemented, we will >> > also have the ability to override setting per session / query. >> > That was the plan all along. >> > >> > > >> > > Those are my thoughts so far... I'll see about doing a POC of some of >> > what >> > > I have described above >> > >> > Thanks :) >> > >> > > >> > > Cheers, >> > > >> > > John >> > > >> > > >> > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell >> > wrote: >> > > >> > > > Hi Emmanuel, >> > > > >> > > > I'll take a look at what is there, and I'll get up and running on >> IRC. >> > > > >> > > > I'll particularly look at the time-series issue - non-trivial I >> think. >> > > > >> > > > Cheers, >> > > > >> > > > John >> > > > >> > > > >> > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < >> > emmanuel at hibernate.org> >> > > > wrote: >> > > > >> > > >> Hi John, >> > > >> >> > > >> I thought I had replied to you on Friday but apparently the email >> > never >> > > >> went through :/ >> > > >> >> > > >> That is good news :) >> > > >> Jonathan worked on a Cassandra prototype but had to drop due to >> other >> > > >> duties. He pushed everything at >> > > >> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra >> > > >> >> > > >> Have a look at what he has done and come ask any question to >> Gunnar, >> > > >> Davide or me. There are a bunch of moving pieces. We are mostly on >> > > >> freenode?s #hibernate-dev ( you need a freenode login >> > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic to >> > IRC, >> > > >> let me know and we will find alternatives. >> > > >> >> > > >> The most interesting challenge will be to see how we can map time >> > series >> > > >> into a collection and make sure we let the user decide how much he >> > wants to >> > > >> load. >> > > >> >> > > >> Emmanuel >> > > >> >> > > >> On 16 Jul 2014, at 13:17, John Worrell wrote: >> > > >> >> > > >> > Hi, >> > > >> > >> > > >> > I'm interested in contributing to the Cassandra module of >> > Hibernate-OGM >> > > >> - >> > > >> > what would be the baest way to go about this? >> > > >> > >> > > >> > Thanks, >> > > >> > >> > > >> > John >> > > >> > _______________________________________________ >> > > >> > hibernate-dev mailing list >> > > >> > hibernate-dev at lists.jboss.org >> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> >> > > >> >> > > > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gunnar at hibernate.org Tue Sep 9 05:36:55 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 9 Sep 2014 11:36:55 +0200 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi, 2014-09-09 11:08 GMT+02:00 John Worrell : > Hi Gunnar, > > Many thanks for the reply - I'll yank down the master... assume it is > merged back to the Jon Halliday fork otherwise I'll need to mess about a > bit. > Not sure when Jon's branch was updated for the last time. Probably you need to rebase (we prefer to work with rebases rather than merge commits) your local branch onto the latest master from upstream. There have been some changes around GridDialect in the last time, mainly about query execution and id generation. Nothing dramatic, though. > Also had some issues with getting connected to C*, understandable, but > also wrt adding tags for the Dog / Breed classes in the > persistence.xml file. not sure whether that is intended to be needed. > You mean the classes from the "Getting Started" example, right? The tags should not be required, the example runs as is e.g. on Infinispan. What happens if you don't add those? Cheers, > > John > --Gunnar On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling wrote: > >> Hi John, >> >> 2014-09-09 10:33 GMT+02:00 John Worrell : >> >>> Hi Emmanuel & Gunnar, >>> >>> Many thanks for your detailed responses - and nice to chat with Gunnar a >>> week or so back. Again I have to apologise for radio silence - my day job >>> suddenly ate all my waking functional time - so progress has been very >>> slow. >>> >> >> No worries, we are very glad about your help. >> >> I'm getting deeper into the code now, and starting a POC... which is >>> leading me to some more detailed questions. Basically, what I am doing is >>> to run the examples and to look at things that seem to be missing, and >>> toi >>> understand the data that is being passed around in the various options >>> classes, so I can make a more informed implementation >>> >> >> Sounds very reasonable. I also can recommend to take a look at the >> MongoDB dialect and the persistent representations it creates in the >> datastore as it can comfortably be browsed e.g. using the mongo command >> line client. That's how I got to understand many things of the interaction >> between engine and dialects. >> >> If you have any ideas where the dialect SPI documentation can be improved >> to facilitate an easier understanding of how pieces work together, let me >> know. >> >> The key question in my mind at the moment is that of the relationship >>> between the base Hibernate Dialect class and the GridDialect interface >> >> >> OGM has its own pseudo implementation of ORM's Dialect contract, >> OgmDialect, but this should hardly ever play a role during OGM development. >> OGM's main contract towards dialects is GridDialect. >> >> The reason for exposing GridDialect on the pseudo OgmDialect is that it >> is our backdoor to make GridDialect available to >> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >> inject the GridDialect in a more straight-forward way due to some >> limitations in the way we integrate with the ORM engine. >> >> >>> - I >>> look at the OgmTableGenerator which is attempting to access a CF / table >>> that is not yet created - I figured I understand what was happening here, >>> and make appropriate extensions / fixes first. So, currently fighting my >>> way through generating the sequence tables, and wondering why >>> OgmSequnceGenerator wraps OgmtableGenerator. >>> >> >> Just to be sure, are you looking at the latest master? There have been >> some changes around these generator classes recently, they are in a much >> cleaner state than they used to be. >> >> The reason for the wrapping is that when using the SEQUENCE strategy in >> cases where the store actually does not natively support sequences, we fall >> back to TABLE. Currently we only support a "native" SEQUENCE strategy for >> Neo4j which allows to map sequences as nodes in a reasonable manner, >> whereas all the other dialects use the table fallback. >> GridDialect#supportsSequences() is evaluated to find out whether the >> delegation needs to be done or not. >> >> You also could take a look at Neo4jSequenceGenerator which creates the >> sequence nodes in the datastore based on the registered >> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >> these types on the dialect SPI, I'm looking into ways for allowing the >> distinction of the two in a more abstract way, mainly based on >> IdSourceKeyMetadata. >> >> Hope that helps, I'll be very happy to answer any follow-up questions. >> Thanks again for your help with the Cassandra dialect, I'm looking forward >> to this dialect very much! >> >> >>> >>> Cheers, >>> >>> John >>> >> >> --Gunnar >> >> >>> >>> >>> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard < >>> emmanuel at hibernate.org> >>> wrote: >>> >>> > On Thu 2014-08-07 9:10, John Worrell wrote: >>> > > Hi Emmanuel et al., >>> > > >>> > > My apologies for the log radio silence. I've taken a look at the >>> > code-base >>> > > on Jon Halliday's repo, and have set up a nick on freenode - >>> #jlesinge. >>> > >>> > No worries I was on holidays. >>> > And you email was the few lucky ones that I had to delay as it required >>> > thinking ;) >>> > >>> > > >>> > > On the time-series question I was wondering how you envisaged the >>> data >>> > > stored: I tend to think of a single row under an primary key with an >>> > > object-instance per column. Now what we have typically done >>> (generally >>> > the >>> > > data has been immutable) is to store the data serialized as a blob >>> (JSON >>> > or >>> > > XML), but I understand you do not favour this approach. With this >>> sort of >>> > > model I imagine the collection is then all the objects stored in the >>> row, >>> > > and the challenge is to page through the objects in the row. >>> > >>> > Actually it is one of the valid strategies. >>> > If I understand you well, you want to create: >>> > >>> > - one row per time series generating object (say a thermometer) >>> > - the column names of that row would be a timestamp of time at bay >>> > - the value would be a JSON structure containing the data at bay for >>> > that specific time. >>> > >>> > That is one of the valid approach. But I think we need to support >>> > several: >>> > >>> > - simple column if the data is literally a single element (temperature) >>> > - JSON structure for more complex data per time event >>> > - key pointing to the detailed data somewhere else in the cluster >>> > >>> > The latest would be done in two phases, you load all the keys you are >>> > interested in matching your time range and then do a multiget of sort >>> to >>> > load the data. >>> > >>> > It seems datastax tends to recommend 1 or 2 (denormalization FTW). >>> > >>> > I don't know but there is also the notion of super column which is a >>> > grouping of columns that might also address our composite problem >>> > assuming they can be used for dynamic column families. >>> > >>> > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra >>> > >>> > >>> http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ >>> > http://www.datastax.com/docs/1.0/ddl/column_family >>> > >>> > > >>> > > An approach we have often taken is to create multiple copies of data >>> in >>> > > different (obviously works well only for immutable objects) or >>> better to >>> > >>> > Yes, that is a feature that I would like OGM to automate for the user. >>> > It declaratively defines the denormalization approaches he wants and >>> the >>> > engine does the persistence. >>> > Next the query engine uses that knowledge to find the best path (or >>> only >>> > possible path in the case of Cassandra :) ) >>> > >>> > > create a table of keys to a main table where in either approach the >>> > > row-keys are effectively a foreign-key and there is column per >>> object >>> > > associated through the foreign-key. Another approach though might be >>> to >>> > use >>> > > a column with type list (or set, or map) to contain keys to the >>> > associated >>> > > objects - this would be a little like the extensions Oracle have for >>> > > mapping 1-* associations, though with the caveat that a column of >>> > > collection type may only contain 64k elements. I wondered if some >>> though >>> > > had been given to this strategy (which I must admit I have not yet >>> used >>> > > myself). >>> > >>> > I am not aware of that approach. >>> > >>> > > >>> > > It seems very likely that different mapping strategies should be >>> > > specifiable, but then I have still to understand how these might fit >>> with >>> > > treiid. >>> > >>> > Forget Teiid for now. We will likely start with the HQL->Walker and do >>> > our own proto query engine before layering Teiid. >>> > >>> > > >>> > > Can I ask about assumptions: is it fair to assume that for >>> Cassandra, OGM >>> > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This >>> would >>> > > certainly make life simpler. >>> > >>> > Yes that's fine. >>> > >>> > > >>> > > An issue I don't see addressed is the choice of consistency-level >>> (read >>> > or >>> > > write) and I wondered if there was a plan for this? Assumptions can >>> be >>> > made >>> > > on a per table basis, but, certainly for ad hoc queries, it is >>> important >>> > > think to have the flexibility to specify on a per-query basis. >>> > >>> > That's planned. We have an option system that allow for entity / >>> > property overriding of a global setting. While not implemented, we will >>> > also have the ability to override setting per session / query. >>> > That was the plan all along. >>> > >>> > > >>> > > Those are my thoughts so far... I'll see about doing a POC of some of >>> > what >>> > > I have described above >>> > >>> > Thanks :) >>> > >>> > > >>> > > Cheers, >>> > > >>> > > John >>> > > >>> > > >>> > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell >>> > wrote: >>> > > >>> > > > Hi Emmanuel, >>> > > > >>> > > > I'll take a look at what is there, and I'll get up and running on >>> IRC. >>> > > > >>> > > > I'll particularly look at the time-series issue - non-trivial I >>> think. >>> > > > >>> > > > Cheers, >>> > > > >>> > > > John >>> > > > >>> > > > >>> > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < >>> > emmanuel at hibernate.org> >>> > > > wrote: >>> > > > >>> > > >> Hi John, >>> > > >> >>> > > >> I thought I had replied to you on Friday but apparently the email >>> > never >>> > > >> went through :/ >>> > > >> >>> > > >> That is good news :) >>> > > >> Jonathan worked on a Cassandra prototype but had to drop due to >>> other >>> > > >> duties. He pushed everything at >>> > > >> >>> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra >>> > > >> >>> > > >> Have a look at what he has done and come ask any question to >>> Gunnar, >>> > > >> Davide or me. There are a bunch of moving pieces. We are mostly on >>> > > >> freenode?s #hibernate-dev ( you need a freenode login >>> > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic to >>> > IRC, >>> > > >> let me know and we will find alternatives. >>> > > >> >>> > > >> The most interesting challenge will be to see how we can map time >>> > series >>> > > >> into a collection and make sure we let the user decide how much he >>> > wants to >>> > > >> load. >>> > > >> >>> > > >> Emmanuel >>> > > >> >>> > > >> On 16 Jul 2014, at 13:17, John Worrell >>> wrote: >>> > > >> >>> > > >> > Hi, >>> > > >> > >>> > > >> > I'm interested in contributing to the Cassandra module of >>> > Hibernate-OGM >>> > > >> - >>> > > >> > what would be the baest way to go about this? >>> > > >> > >>> > > >> > Thanks, >>> > > >> > >>> > > >> > John >>> > > >> > _______________________________________________ >>> > > >> > hibernate-dev mailing list >>> > > >> > hibernate-dev at lists.jboss.org >>> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >> >>> > > >> >>> > > > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > From Itai at forter.com Tue Sep 9 06:03:39 2014 From: Itai at forter.com (Itai Frenkel) Date: Tue, 9 Sep 2014 10:03:39 +0000 Subject: [hibernate-dev] Possible bug in hibernate-validator ValidatorImpl In-Reply-To: References: <1408617520714.61420@forter.com>, Message-ID: <1410257019798.46369@forter.com> Opened https://hibernate.atlassian.net/browse/HV-928 thanks :) ________________________________ From: gunnar.morling at googlemail.com on behalf of Gunnar Morling Sent: Thursday, August 21, 2014 2:57 PM To: Itai Frenkel Cc: hibernate-dev at lists.jboss.org Subject: Re: [hibernate-dev] Possible bug in hibernate-validator ValidatorImpl Hi, 2014-08-21 12:38 GMT+02:00 Itai Frenkel >: Hello, TL;DR: Need an opinion if to open a JIRA (since reproduction is very tricky) I am using the @UnwrapValidatedValue with a custom Guava OptionalUnwrapper and sometimes OptionalUnwrapper#getValidatedValueType() is called also for non-Optional<> fields. The bug reproduction is sporadic and tricky. If you say sporadic, does it mean validating one and the same POJO sometimes shows the issue and in some other cases it doesn't, without altering any parts of the code? I managed to pinpoint it to ValidatorImpl#setValidatedValueHandlerToValueContextIfPresent() that does not perform valueContext.setValidatedValueHandler( null ) when there is no need for an unwrapper. Since valueContext is re-used between fields, it is possible for the OptionalUnwrapper to be first called for Optional fields and then re-used for non-Optional fields with the same validatedValueHandler of the Optional field. Interesting, this doesn't seem correct indeed. Without having a closer look I'd say the un-wrapper should be reset on the context between validation of different properties. If the code owner could quickly comment on this, it would be great. It sounds like a legitimate bug description, so I suggest you move forward and open an issue in JIRA (https://hibernate.atlassian.net/browse/HV). It would be great if you could attach a complete executable test case which demonstrates the issue. below are some code snippets I used. public class SomePOJO { @DecimalMin(value="0", inclusive=true) public Integer x = -1; @UnwrapValidatedValue @DecimalMin(value="1", inclusive=true) public Optional y = Optional.of(-1); @DecimalMin(value="0", inclusive=true) public Integer z = -1; } public class OptionalUnwrapper extends ValidatedValueUnwrapper> { private final TypeResolver typeResolver; public OptionalUnwrapper() { typeResolver = new TypeResolver(); } @Override public Object handleValidatedValue(Optional optional) { return optional == null? null : optional.orNull(); } @Override public Type getValidatedValueType(Type valueType) { final TypeToken typeToken = TypeToken.of(valueType); if (typeToken.getRawType().isAssignableFrom(Optional.class)) { Type rawType = typeToken.resolveType(Optional.class.getTypeParameters()[0]).getType(); return rawType; } else { Type rawType = typeToken.getType(); Preconditions.checkArgument(false, "type " + rawType + " is not supported by " + this.getClass() ); return null; } } } Thanks for reporting this issue, much appreciated! Cheers, --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From jlesinge at gmail.com Tue Sep 9 06:55:19 2014 From: jlesinge at gmail.com (John Worrell) Date: Tue, 9 Sep 2014 11:55:19 +0100 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi Gunnar, Wrt the tags - partly it is an issue with Eclipse JPA which complains if the tags are absent, but I think it *may* actually not make any difference to the examples - the real issue lies with the code not picking up the sequences to generate properly, and as you point out that may now be fixed in the latest master. I'll look at a rebase. Thanks, John On Tue, Sep 9, 2014 at 10:36 AM, Gunnar Morling wrote: > Hi, > > 2014-09-09 11:08 GMT+02:00 John Worrell : > >> Hi Gunnar, >> >> Many thanks for the reply - I'll yank down the master... assume it is >> merged back to the Jon Halliday fork otherwise I'll need to mess about a >> bit. >> > > Not sure when Jon's branch was updated for the last time. > > Probably you need to rebase (we prefer to work with rebases rather than > merge commits) your local branch onto the latest master from upstream. > There have been some changes around GridDialect in the last time, mainly > about query execution and id generation. Nothing dramatic, though. > > >> Also had some issues with getting connected to C*, understandable, but >> also wrt adding tags for the Dog / Breed classes in the >> persistence.xml file. not sure whether that is intended to be needed. >> > > You mean the classes from the "Getting Started" example, right? The > tags should not be required, the example runs as is e.g. on > Infinispan. What happens if you don't add those? > > Cheers, >> >> John >> > > --Gunnar > > On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling >> wrote: >> >>> Hi John, >>> >>> 2014-09-09 10:33 GMT+02:00 John Worrell : >>> >>>> Hi Emmanuel & Gunnar, >>>> >>>> Many thanks for your detailed responses - and nice to chat with Gunnar a >>>> week or so back. Again I have to apologise for radio silence - my day >>>> job >>>> suddenly ate all my waking functional time - so progress has been very >>>> slow. >>>> >>> >>> No worries, we are very glad about your help. >>> >>> I'm getting deeper into the code now, and starting a POC... which is >>>> leading me to some more detailed questions. Basically, what I am doing >>>> is >>>> to run the examples and to look at things that seem to be missing, and >>>> toi >>>> understand the data that is being passed around in the various options >>>> classes, so I can make a more informed implementation >>>> >>> >>> Sounds very reasonable. I also can recommend to take a look at the >>> MongoDB dialect and the persistent representations it creates in the >>> datastore as it can comfortably be browsed e.g. using the mongo command >>> line client. That's how I got to understand many things of the interaction >>> between engine and dialects. >>> >>> If you have any ideas where the dialect SPI documentation can be >>> improved to facilitate an easier understanding of how pieces work together, >>> let me know. >>> >>> The key question in my mind at the moment is that of the relationship >>>> between the base Hibernate Dialect class and the GridDialect interface >>> >>> >>> OGM has its own pseudo implementation of ORM's Dialect contract, >>> OgmDialect, but this should hardly ever play a role during OGM development. >>> OGM's main contract towards dialects is GridDialect. >>> >>> The reason for exposing GridDialect on the pseudo OgmDialect is that it >>> is our backdoor to make GridDialect available to >>> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >>> inject the GridDialect in a more straight-forward way due to some >>> limitations in the way we integrate with the ORM engine. >>> >>> >>>> - I >>>> look at the OgmTableGenerator which is attempting to access a CF / table >>>> that is not yet created - I figured I understand what was happening >>>> here, >>>> and make appropriate extensions / fixes first. So, currently fighting my >>>> way through generating the sequence tables, and wondering why >>>> OgmSequnceGenerator wraps OgmtableGenerator. >>>> >>> >>> Just to be sure, are you looking at the latest master? There have been >>> some changes around these generator classes recently, they are in a much >>> cleaner state than they used to be. >>> >>> The reason for the wrapping is that when using the SEQUENCE strategy in >>> cases where the store actually does not natively support sequences, we fall >>> back to TABLE. Currently we only support a "native" SEQUENCE strategy for >>> Neo4j which allows to map sequences as nodes in a reasonable manner, >>> whereas all the other dialects use the table fallback. >>> GridDialect#supportsSequences() is evaluated to find out whether the >>> delegation needs to be done or not. >>> >>> You also could take a look at Neo4jSequenceGenerator which creates the >>> sequence nodes in the datastore based on the registered >>> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >>> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >>> these types on the dialect SPI, I'm looking into ways for allowing the >>> distinction of the two in a more abstract way, mainly based on >>> IdSourceKeyMetadata. >>> >>> Hope that helps, I'll be very happy to answer any follow-up questions. >>> Thanks again for your help with the Cassandra dialect, I'm looking forward >>> to this dialect very much! >>> >>> >>>> >>>> Cheers, >>>> >>>> John >>>> >>> >>> --Gunnar >>> >>> >>>> >>>> >>>> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard < >>>> emmanuel at hibernate.org> >>>> wrote: >>>> >>>> > On Thu 2014-08-07 9:10, John Worrell wrote: >>>> > > Hi Emmanuel et al., >>>> > > >>>> > > My apologies for the log radio silence. I've taken a look at the >>>> > code-base >>>> > > on Jon Halliday's repo, and have set up a nick on freenode - >>>> #jlesinge. >>>> > >>>> > No worries I was on holidays. >>>> > And you email was the few lucky ones that I had to delay as it >>>> required >>>> > thinking ;) >>>> > >>>> > > >>>> > > On the time-series question I was wondering how you envisaged the >>>> data >>>> > > stored: I tend to think of a single row under an primary key with an >>>> > > object-instance per column. Now what we have typically done >>>> (generally >>>> > the >>>> > > data has been immutable) is to store the data serialized as a blob >>>> (JSON >>>> > or >>>> > > XML), but I understand you do not favour this approach. With this >>>> sort of >>>> > > model I imagine the collection is then all the objects stored in >>>> the row, >>>> > > and the challenge is to page through the objects in the row. >>>> > >>>> > Actually it is one of the valid strategies. >>>> > If I understand you well, you want to create: >>>> > >>>> > - one row per time series generating object (say a thermometer) >>>> > - the column names of that row would be a timestamp of time at bay >>>> > - the value would be a JSON structure containing the data at bay for >>>> > that specific time. >>>> > >>>> > That is one of the valid approach. But I think we need to support >>>> > several: >>>> > >>>> > - simple column if the data is literally a single element >>>> (temperature) >>>> > - JSON structure for more complex data per time event >>>> > - key pointing to the detailed data somewhere else in the cluster >>>> > >>>> > The latest would be done in two phases, you load all the keys you are >>>> > interested in matching your time range and then do a multiget of sort >>>> to >>>> > load the data. >>>> > >>>> > It seems datastax tends to recommend 1 or 2 (denormalization FTW). >>>> > >>>> > I don't know but there is also the notion of super column which is a >>>> > grouping of columns that might also address our composite problem >>>> > assuming they can be used for dynamic column families. >>>> > >>>> > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra >>>> > >>>> > >>>> http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ >>>> > http://www.datastax.com/docs/1.0/ddl/column_family >>>> > >>>> > > >>>> > > An approach we have often taken is to create multiple copies of >>>> data in >>>> > > different (obviously works well only for immutable objects) or >>>> better to >>>> > >>>> > Yes, that is a feature that I would like OGM to automate for the user. >>>> > It declaratively defines the denormalization approaches he wants and >>>> the >>>> > engine does the persistence. >>>> > Next the query engine uses that knowledge to find the best path (or >>>> only >>>> > possible path in the case of Cassandra :) ) >>>> > >>>> > > create a table of keys to a main table where in either approach the >>>> > > row-keys are effectively a foreign-key and there is column per >>>> object >>>> > > associated through the foreign-key. Another approach though might >>>> be to >>>> > use >>>> > > a column with type list (or set, or map) to contain keys to the >>>> > associated >>>> > > objects - this would be a little like the extensions Oracle have for >>>> > > mapping 1-* associations, though with the caveat that a column of >>>> > > collection type may only contain 64k elements. I wondered if some >>>> though >>>> > > had been given to this strategy (which I must admit I have not yet >>>> used >>>> > > myself). >>>> > >>>> > I am not aware of that approach. >>>> > >>>> > > >>>> > > It seems very likely that different mapping strategies should be >>>> > > specifiable, but then I have still to understand how these might >>>> fit with >>>> > > treiid. >>>> > >>>> > Forget Teiid for now. We will likely start with the HQL->Walker and do >>>> > our own proto query engine before layering Teiid. >>>> > >>>> > > >>>> > > Can I ask about assumptions: is it fair to assume that for >>>> Cassandra, OGM >>>> > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This >>>> would >>>> > > certainly make life simpler. >>>> > >>>> > Yes that's fine. >>>> > >>>> > > >>>> > > An issue I don't see addressed is the choice of consistency-level >>>> (read >>>> > or >>>> > > write) and I wondered if there was a plan for this? Assumptions can >>>> be >>>> > made >>>> > > on a per table basis, but, certainly for ad hoc queries, it is >>>> important >>>> > > think to have the flexibility to specify on a per-query basis. >>>> > >>>> > That's planned. We have an option system that allow for entity / >>>> > property overriding of a global setting. While not implemented, we >>>> will >>>> > also have the ability to override setting per session / query. >>>> > That was the plan all along. >>>> > >>>> > > >>>> > > Those are my thoughts so far... I'll see about doing a POC of some >>>> of >>>> > what >>>> > > I have described above >>>> > >>>> > Thanks :) >>>> > >>>> > > >>>> > > Cheers, >>>> > > >>>> > > John >>>> > > >>>> > > >>>> > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell >>>> > wrote: >>>> > > >>>> > > > Hi Emmanuel, >>>> > > > >>>> > > > I'll take a look at what is there, and I'll get up and running on >>>> IRC. >>>> > > > >>>> > > > I'll particularly look at the time-series issue - non-trivial I >>>> think. >>>> > > > >>>> > > > Cheers, >>>> > > > >>>> > > > John >>>> > > > >>>> > > > >>>> > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < >>>> > emmanuel at hibernate.org> >>>> > > > wrote: >>>> > > > >>>> > > >> Hi John, >>>> > > >> >>>> > > >> I thought I had replied to you on Friday but apparently the email >>>> > never >>>> > > >> went through :/ >>>> > > >> >>>> > > >> That is good news :) >>>> > > >> Jonathan worked on a Cassandra prototype but had to drop due to >>>> other >>>> > > >> duties. He pushed everything at >>>> > > >> >>>> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra >>>> > > >> >>>> > > >> Have a look at what he has done and come ask any question to >>>> Gunnar, >>>> > > >> Davide or me. There are a bunch of moving pieces. We are mostly >>>> on >>>> > > >> freenode?s #hibernate-dev ( you need a freenode login >>>> > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic >>>> to >>>> > IRC, >>>> > > >> let me know and we will find alternatives. >>>> > > >> >>>> > > >> The most interesting challenge will be to see how we can map time >>>> > series >>>> > > >> into a collection and make sure we let the user decide how much >>>> he >>>> > wants to >>>> > > >> load. >>>> > > >> >>>> > > >> Emmanuel >>>> > > >> >>>> > > >> On 16 Jul 2014, at 13:17, John Worrell >>>> wrote: >>>> > > >> >>>> > > >> > Hi, >>>> > > >> > >>>> > > >> > I'm interested in contributing to the Cassandra module of >>>> > Hibernate-OGM >>>> > > >> - >>>> > > >> > what would be the baest way to go about this? >>>> > > >> > >>>> > > >> > Thanks, >>>> > > >> > >>>> > > >> > John >>>> > > >> > _______________________________________________ >>>> > > >> > hibernate-dev mailing list >>>> > > >> > hibernate-dev at lists.jboss.org >>>> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > > >> >>>> > > >> >>>> > > > >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> > From gunnar at hibernate.org Tue Sep 9 08:06:17 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 9 Sep 2014 14:06:17 +0200 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi, 2014-09-09 12:55 GMT+02:00 John Worrell : > Hi Gunnar, > > Wrt the tags - partly it is an issue with Eclipse JPA which > complains if the tags are absent, but I think it *may* actually not > make any difference to the examples - the real issue lies with the code not > picking up the sequences to generate properly, and as you point out that > may now be fixed in the latest master. > To provide some more details, it's a dialect-specific implementation of the SchemaDefiner contract which is in charge of the schema initialization. The specific implementation type is to be returned from DatastoreProvider#getSchemaDefinerType(). The SchemaDefiner is invoked by the engine after session factory initialization (eventually it will only be invoked if required so by the "hbm2ddl.auto" setting). That contract is still experimental at this time, we need to flesh it out in more detail, also based on the feedback what's needed for Cassandra (as it is the first store with a fixed schema). Does Cassandra have any counterpart to physical sequences as e.g. in Oracle? If not (and it can not be emulated in a meaningful way as we do for Neo4j), GridDialect#supportsSequences() would have to return false, and the table-based strategy needs to be implemented. I'll look at a rebase. > > Thanks, > > John > Hth, --Gunnar > On Tue, Sep 9, 2014 at 10:36 AM, Gunnar Morling > wrote: > >> Hi, >> >> 2014-09-09 11:08 GMT+02:00 John Worrell : >> >>> Hi Gunnar, >>> >>> Many thanks for the reply - I'll yank down the master... assume it is >>> merged back to the Jon Halliday fork otherwise I'll need to mess about a >>> bit. >>> >> >> Not sure when Jon's branch was updated for the last time. >> >> Probably you need to rebase (we prefer to work with rebases rather than >> merge commits) your local branch onto the latest master from upstream. >> There have been some changes around GridDialect in the last time, mainly >> about query execution and id generation. Nothing dramatic, though. >> >> >>> Also had some issues with getting connected to C*, understandable, but >>> also wrt adding tags for the Dog / Breed classes in the >>> persistence.xml file. not sure whether that is intended to be needed. >>> >> >> You mean the classes from the "Getting Started" example, right? The >> tags should not be required, the example runs as is e.g. on >> Infinispan. What happens if you don't add those? >> >> Cheers, >>> >>> John >>> >> >> --Gunnar >> >> On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling >>> wrote: >>> >>>> Hi John, >>>> >>>> 2014-09-09 10:33 GMT+02:00 John Worrell : >>>> >>>>> Hi Emmanuel & Gunnar, >>>>> >>>>> Many thanks for your detailed responses - and nice to chat with Gunnar >>>>> a >>>>> week or so back. Again I have to apologise for radio silence - my day >>>>> job >>>>> suddenly ate all my waking functional time - so progress has been very >>>>> slow. >>>>> >>>> >>>> No worries, we are very glad about your help. >>>> >>>> I'm getting deeper into the code now, and starting a POC... which is >>>>> leading me to some more detailed questions. Basically, what I am doing >>>>> is >>>>> to run the examples and to look at things that seem to be missing, and >>>>> toi >>>>> understand the data that is being passed around in the various options >>>>> classes, so I can make a more informed implementation >>>>> >>>> >>>> Sounds very reasonable. I also can recommend to take a look at the >>>> MongoDB dialect and the persistent representations it creates in the >>>> datastore as it can comfortably be browsed e.g. using the mongo command >>>> line client. That's how I got to understand many things of the interaction >>>> between engine and dialects. >>>> >>>> If you have any ideas where the dialect SPI documentation can be >>>> improved to facilitate an easier understanding of how pieces work together, >>>> let me know. >>>> >>>> The key question in my mind at the moment is that of the relationship >>>>> between the base Hibernate Dialect class and the GridDialect interface >>>> >>>> >>>> OGM has its own pseudo implementation of ORM's Dialect contract, >>>> OgmDialect, but this should hardly ever play a role during OGM development. >>>> OGM's main contract towards dialects is GridDialect. >>>> >>>> The reason for exposing GridDialect on the pseudo OgmDialect is that it >>>> is our backdoor to make GridDialect available to >>>> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >>>> inject the GridDialect in a more straight-forward way due to some >>>> limitations in the way we integrate with the ORM engine. >>>> >>>> >>>>> - I >>>>> look at the OgmTableGenerator which is attempting to access a CF / >>>>> table >>>>> that is not yet created - I figured I understand what was happening >>>>> here, >>>>> and make appropriate extensions / fixes first. So, currently fighting >>>>> my >>>>> way through generating the sequence tables, and wondering why >>>>> OgmSequnceGenerator wraps OgmtableGenerator. >>>>> >>>> >>>> Just to be sure, are you looking at the latest master? There have been >>>> some changes around these generator classes recently, they are in a much >>>> cleaner state than they used to be. >>>> >>>> The reason for the wrapping is that when using the SEQUENCE strategy in >>>> cases where the store actually does not natively support sequences, we fall >>>> back to TABLE. Currently we only support a "native" SEQUENCE strategy for >>>> Neo4j which allows to map sequences as nodes in a reasonable manner, >>>> whereas all the other dialects use the table fallback. >>>> GridDialect#supportsSequences() is evaluated to find out whether the >>>> delegation needs to be done or not. >>>> >>>> You also could take a look at Neo4jSequenceGenerator which creates the >>>> sequence nodes in the datastore based on the registered >>>> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >>>> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >>>> these types on the dialect SPI, I'm looking into ways for allowing the >>>> distinction of the two in a more abstract way, mainly based on >>>> IdSourceKeyMetadata. >>>> >>>> Hope that helps, I'll be very happy to answer any follow-up questions. >>>> Thanks again for your help with the Cassandra dialect, I'm looking forward >>>> to this dialect very much! >>>> >>>> >>>>> >>>>> Cheers, >>>>> >>>>> John >>>>> >>>> >>>> --Gunnar >>>> >>>> >>>>> >>>>> >>>>> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard < >>>>> emmanuel at hibernate.org> >>>>> wrote: >>>>> >>>>> > On Thu 2014-08-07 9:10, John Worrell wrote: >>>>> > > Hi Emmanuel et al., >>>>> > > >>>>> > > My apologies for the log radio silence. I've taken a look at the >>>>> > code-base >>>>> > > on Jon Halliday's repo, and have set up a nick on freenode - >>>>> #jlesinge. >>>>> > >>>>> > No worries I was on holidays. >>>>> > And you email was the few lucky ones that I had to delay as it >>>>> required >>>>> > thinking ;) >>>>> > >>>>> > > >>>>> > > On the time-series question I was wondering how you envisaged the >>>>> data >>>>> > > stored: I tend to think of a single row under an primary key with >>>>> an >>>>> > > object-instance per column. Now what we have typically done >>>>> (generally >>>>> > the >>>>> > > data has been immutable) is to store the data serialized as a blob >>>>> (JSON >>>>> > or >>>>> > > XML), but I understand you do not favour this approach. With this >>>>> sort of >>>>> > > model I imagine the collection is then all the objects stored in >>>>> the row, >>>>> > > and the challenge is to page through the objects in the row. >>>>> > >>>>> > Actually it is one of the valid strategies. >>>>> > If I understand you well, you want to create: >>>>> > >>>>> > - one row per time series generating object (say a thermometer) >>>>> > - the column names of that row would be a timestamp of time at bay >>>>> > - the value would be a JSON structure containing the data at bay for >>>>> > that specific time. >>>>> > >>>>> > That is one of the valid approach. But I think we need to support >>>>> > several: >>>>> > >>>>> > - simple column if the data is literally a single element >>>>> (temperature) >>>>> > - JSON structure for more complex data per time event >>>>> > - key pointing to the detailed data somewhere else in the cluster >>>>> > >>>>> > The latest would be done in two phases, you load all the keys you are >>>>> > interested in matching your time range and then do a multiget of >>>>> sort to >>>>> > load the data. >>>>> > >>>>> > It seems datastax tends to recommend 1 or 2 (denormalization FTW). >>>>> > >>>>> > I don't know but there is also the notion of super column which is a >>>>> > grouping of columns that might also address our composite problem >>>>> > assuming they can be used for dynamic column families. >>>>> > >>>>> > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra >>>>> > >>>>> > >>>>> http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ >>>>> > http://www.datastax.com/docs/1.0/ddl/column_family >>>>> > >>>>> > > >>>>> > > An approach we have often taken is to create multiple copies of >>>>> data in >>>>> > > different (obviously works well only for immutable objects) or >>>>> better to >>>>> > >>>>> > Yes, that is a feature that I would like OGM to automate for the >>>>> user. >>>>> > It declaratively defines the denormalization approaches he wants and >>>>> the >>>>> > engine does the persistence. >>>>> > Next the query engine uses that knowledge to find the best path (or >>>>> only >>>>> > possible path in the case of Cassandra :) ) >>>>> > >>>>> > > create a table of keys to a main table where in either approach the >>>>> > > row-keys are effectively a foreign-key and there is column per >>>>> object >>>>> > > associated through the foreign-key. Another approach though might >>>>> be to >>>>> > use >>>>> > > a column with type list (or set, or map) to contain keys to the >>>>> > associated >>>>> > > objects - this would be a little like the extensions Oracle have >>>>> for >>>>> > > mapping 1-* associations, though with the caveat that a column of >>>>> > > collection type may only contain 64k elements. I wondered if some >>>>> though >>>>> > > had been given to this strategy (which I must admit I have not yet >>>>> used >>>>> > > myself). >>>>> > >>>>> > I am not aware of that approach. >>>>> > >>>>> > > >>>>> > > It seems very likely that different mapping strategies should be >>>>> > > specifiable, but then I have still to understand how these might >>>>> fit with >>>>> > > treiid. >>>>> > >>>>> > Forget Teiid for now. We will likely start with the HQL->Walker and >>>>> do >>>>> > our own proto query engine before layering Teiid. >>>>> > >>>>> > > >>>>> > > Can I ask about assumptions: is it fair to assume that for >>>>> Cassandra, OGM >>>>> > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? >>>>> This would >>>>> > > certainly make life simpler. >>>>> > >>>>> > Yes that's fine. >>>>> > >>>>> > > >>>>> > > An issue I don't see addressed is the choice of consistency-level >>>>> (read >>>>> > or >>>>> > > write) and I wondered if there was a plan for this? Assumptions >>>>> can be >>>>> > made >>>>> > > on a per table basis, but, certainly for ad hoc queries, it is >>>>> important >>>>> > > think to have the flexibility to specify on a per-query basis. >>>>> > >>>>> > That's planned. We have an option system that allow for entity / >>>>> > property overriding of a global setting. While not implemented, we >>>>> will >>>>> > also have the ability to override setting per session / query. >>>>> > That was the plan all along. >>>>> > >>>>> > > >>>>> > > Those are my thoughts so far... I'll see about doing a POC of some >>>>> of >>>>> > what >>>>> > > I have described above >>>>> > >>>>> > Thanks :) >>>>> > >>>>> > > >>>>> > > Cheers, >>>>> > > >>>>> > > John >>>>> > > >>>>> > > >>>>> > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell >>>>> > wrote: >>>>> > > >>>>> > > > Hi Emmanuel, >>>>> > > > >>>>> > > > I'll take a look at what is there, and I'll get up and running >>>>> on IRC. >>>>> > > > >>>>> > > > I'll particularly look at the time-series issue - non-trivial I >>>>> think. >>>>> > > > >>>>> > > > Cheers, >>>>> > > > >>>>> > > > John >>>>> > > > >>>>> > > > >>>>> > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < >>>>> > emmanuel at hibernate.org> >>>>> > > > wrote: >>>>> > > > >>>>> > > >> Hi John, >>>>> > > >> >>>>> > > >> I thought I had replied to you on Friday but apparently the >>>>> email >>>>> > never >>>>> > > >> went through :/ >>>>> > > >> >>>>> > > >> That is good news :) >>>>> > > >> Jonathan worked on a Cassandra prototype but had to drop due to >>>>> other >>>>> > > >> duties. He pushed everything at >>>>> > > >> >>>>> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra >>>>> > > >> >>>>> > > >> Have a look at what he has done and come ask any question to >>>>> Gunnar, >>>>> > > >> Davide or me. There are a bunch of moving pieces. We are mostly >>>>> on >>>>> > > >> freenode?s #hibernate-dev ( you need a freenode login >>>>> > > >> http://freenode.net/faq.shtml#nicksetup ). If you are allergic >>>>> to >>>>> > IRC, >>>>> > > >> let me know and we will find alternatives. >>>>> > > >> >>>>> > > >> The most interesting challenge will be to see how we can map >>>>> time >>>>> > series >>>>> > > >> into a collection and make sure we let the user decide how much >>>>> he >>>>> > wants to >>>>> > > >> load. >>>>> > > >> >>>>> > > >> Emmanuel >>>>> > > >> >>>>> > > >> On 16 Jul 2014, at 13:17, John Worrell >>>>> wrote: >>>>> > > >> >>>>> > > >> > Hi, >>>>> > > >> > >>>>> > > >> > I'm interested in contributing to the Cassandra module of >>>>> > Hibernate-OGM >>>>> > > >> - >>>>> > > >> > what would be the baest way to go about this? >>>>> > > >> > >>>>> > > >> > Thanks, >>>>> > > >> > >>>>> > > >> > John >>>>> > > >> > _______________________________________________ >>>>> > > >> > hibernate-dev mailing list >>>>> > > >> > hibernate-dev at lists.jboss.org >>>>> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > > >> >>>>> > > >> >>>>> > > > >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>> >> > From hardy at hibernate.org Wed Sep 10 16:29:50 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 10 Sep 2014 22:29:50 +0200 Subject: [hibernate-dev] GitHub Split View Message-ID: <20140910202950.GA26975@Sarmakand-2.local> Hi, Not sure for how long it is there already, but GitHub has now a side by side diff view for pull request changes (on the Files changed tab look for the unified vs split buttons). This discovery made my day, so I thought its worth sharing ;-) --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20140910/62db574c/attachment.bin From gunnar at hibernate.org Thu Sep 11 03:33:33 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 11 Sep 2014 09:33:33 +0200 Subject: [hibernate-dev] GitHub Split View In-Reply-To: <20140910202950.GA26975@Sarmakand-2.local> References: <20140910202950.GA26975@Sarmakand-2.local> Message-ID: Yeah, it's a nice improvement. Now they only need to remove that limit of only showing 300 files per diff :) 2014-09-10 22:29 GMT+02:00 Hardy Ferentschik : > Hi, > > Not sure for how long it is there already, but GitHub has now > a side by side diff view for pull request changes (on the Files > changed tab look for the unified vs split buttons). > This discovery made my day, so I thought its worth sharing ;-) > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From jlesinge at gmail.com Thu Sep 11 04:56:53 2014 From: jlesinge at gmail.com (John Worrell) Date: Thu, 11 Sep 2014 09:56:53 +0100 Subject: [hibernate-dev] Contributing to OGM / Cassandra In-Reply-To: References: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org> <20140822162544.GM8223@hibernate.org> Message-ID: Hi Gunnar (& Emmanuel), Thanks again for the info. Chugging on slowly when I get the time. The sequences are an interesting problem: C* does not supply built-in functionality to create sequences. That leaves us with an interesting problem because the standard approach of creating a sequence table would seem to hobble the "write fast" that C* users know and love. Alternatives to the use of a C* table to generate sequences then bring us face to face with the problem of generating id.s on multiple nodes (I assume here that C* is being used in a distributed environment) - we use a home-grown implementation of twitter snow-flake for this purpose. Cheers, John On Tue, Sep 9, 2014 at 1:06 PM, Gunnar Morling wrote: > Hi, > > 2014-09-09 12:55 GMT+02:00 John Worrell : > >> Hi Gunnar, >> >> Wrt the tags - partly it is an issue with Eclipse JPA which >> complains if the tags are absent, but I think it *may* actually not >> make any difference to the examples - the real issue lies with the code not >> picking up the sequences to generate properly, and as you point out that >> may now be fixed in the latest master. >> > > To provide some more details, it's a dialect-specific implementation of > the SchemaDefiner contract which is in charge of the schema initialization. > The specific implementation type is to be returned from > DatastoreProvider#getSchemaDefinerType(). The SchemaDefiner is invoked by > the engine after session factory initialization (eventually it will only be > invoked if required so by the "hbm2ddl.auto" setting). > > That contract is still experimental at this time, we need to flesh it out > in more detail, also based on the feedback what's needed for Cassandra (as > it is the first store with a fixed schema). > > Does Cassandra have any counterpart to physical sequences as e.g. in > Oracle? If not (and it can not be emulated in a meaningful way as we do for > Neo4j), GridDialect#supportsSequences() would have to return false, and the > table-based strategy needs to be implemented. > > I'll look at a rebase. >> >> Thanks, >> >> John >> > > Hth, > > --Gunnar > > >> On Tue, Sep 9, 2014 at 10:36 AM, Gunnar Morling >> wrote: >> >>> Hi, >>> >>> 2014-09-09 11:08 GMT+02:00 John Worrell : >>> >>>> Hi Gunnar, >>>> >>>> Many thanks for the reply - I'll yank down the master... assume it is >>>> merged back to the Jon Halliday fork otherwise I'll need to mess about a >>>> bit. >>>> >>> >>> Not sure when Jon's branch was updated for the last time. >>> >>> Probably you need to rebase (we prefer to work with rebases rather than >>> merge commits) your local branch onto the latest master from upstream. >>> There have been some changes around GridDialect in the last time, mainly >>> about query execution and id generation. Nothing dramatic, though. >>> >>> >>>> Also had some issues with getting connected to C*, understandable, but >>>> also wrt adding tags for the Dog / Breed classes in the >>>> persistence.xml file. not sure whether that is intended to be needed. >>>> >>> >>> You mean the classes from the "Getting Started" example, right? The >>> tags should not be required, the example runs as is e.g. on >>> Infinispan. What happens if you don't add those? >>> >>> Cheers, >>>> >>>> John >>>> >>> >>> --Gunnar >>> >>> On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> 2014-09-09 10:33 GMT+02:00 John Worrell : >>>>> >>>>>> Hi Emmanuel & Gunnar, >>>>>> >>>>>> Many thanks for your detailed responses - and nice to chat with >>>>>> Gunnar a >>>>>> week or so back. Again I have to apologise for radio silence - my day >>>>>> job >>>>>> suddenly ate all my waking functional time - so progress has been >>>>>> very slow. >>>>>> >>>>> >>>>> No worries, we are very glad about your help. >>>>> >>>>> I'm getting deeper into the code now, and starting a POC... which is >>>>>> leading me to some more detailed questions. Basically, what I am >>>>>> doing is >>>>>> to run the examples and to look at things that seem to be missing, >>>>>> and toi >>>>>> understand the data that is being passed around in the various options >>>>>> classes, so I can make a more informed implementation >>>>>> >>>>> >>>>> Sounds very reasonable. I also can recommend to take a look at the >>>>> MongoDB dialect and the persistent representations it creates in the >>>>> datastore as it can comfortably be browsed e.g. using the mongo command >>>>> line client. That's how I got to understand many things of the interaction >>>>> between engine and dialects. >>>>> >>>>> If you have any ideas where the dialect SPI documentation can be >>>>> improved to facilitate an easier understanding of how pieces work together, >>>>> let me know. >>>>> >>>>> The key question in my mind at the moment is that of the relationship >>>>>> between the base Hibernate Dialect class and the GridDialect interface >>>>> >>>>> >>>>> OGM has its own pseudo implementation of ORM's Dialect contract, >>>>> OgmDialect, but this should hardly ever play a role during OGM development. >>>>> OGM's main contract towards dialects is GridDialect. >>>>> >>>>> The reason for exposing GridDialect on the pseudo OgmDialect is that >>>>> it is our backdoor to make GridDialect available to >>>>> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >>>>> inject the GridDialect in a more straight-forward way due to some >>>>> limitations in the way we integrate with the ORM engine. >>>>> >>>>> >>>>>> - I >>>>>> look at the OgmTableGenerator which is attempting to access a CF / >>>>>> table >>>>>> that is not yet created - I figured I understand what was happening >>>>>> here, >>>>>> and make appropriate extensions / fixes first. So, currently fighting >>>>>> my >>>>>> way through generating the sequence tables, and wondering why >>>>>> OgmSequnceGenerator wraps OgmtableGenerator. >>>>>> >>>>> >>>>> Just to be sure, are you looking at the latest master? There have been >>>>> some changes around these generator classes recently, they are in a much >>>>> cleaner state than they used to be. >>>>> >>>>> The reason for the wrapping is that when using the SEQUENCE strategy >>>>> in cases where the store actually does not natively support sequences, we >>>>> fall back to TABLE. Currently we only support a "native" SEQUENCE strategy >>>>> for Neo4j which allows to map sequences as nodes in a reasonable manner, >>>>> whereas all the other dialects use the table fallback. >>>>> GridDialect#supportsSequences() is evaluated to find out whether the >>>>> delegation needs to be done or not. >>>>> >>>>> You also could take a look at Neo4jSequenceGenerator which creates the >>>>> sequence nodes in the datastore based on the registered >>>>> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >>>>> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >>>>> these types on the dialect SPI, I'm looking into ways for allowing the >>>>> distinction of the two in a more abstract way, mainly based on >>>>> IdSourceKeyMetadata. >>>>> >>>>> Hope that helps, I'll be very happy to answer any follow-up questions. >>>>> Thanks again for your help with the Cassandra dialect, I'm looking forward >>>>> to this dialect very much! >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> John >>>>>> >>>>> >>>>> --Gunnar >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard < >>>>>> emmanuel at hibernate.org> >>>>>> wrote: >>>>>> >>>>>> > On Thu 2014-08-07 9:10, John Worrell wrote: >>>>>> > > Hi Emmanuel et al., >>>>>> > > >>>>>> > > My apologies for the log radio silence. I've taken a look at the >>>>>> > code-base >>>>>> > > on Jon Halliday's repo, and have set up a nick on freenode - >>>>>> #jlesinge. >>>>>> > >>>>>> > No worries I was on holidays. >>>>>> > And you email was the few lucky ones that I had to delay as it >>>>>> required >>>>>> > thinking ;) >>>>>> > >>>>>> > > >>>>>> > > On the time-series question I was wondering how you envisaged the >>>>>> data >>>>>> > > stored: I tend to think of a single row under an primary key with >>>>>> an >>>>>> > > object-instance per column. Now what we have typically done >>>>>> (generally >>>>>> > the >>>>>> > > data has been immutable) is to store the data serialized as a >>>>>> blob (JSON >>>>>> > or >>>>>> > > XML), but I understand you do not favour this approach. With this >>>>>> sort of >>>>>> > > model I imagine the collection is then all the objects stored in >>>>>> the row, >>>>>> > > and the challenge is to page through the objects in the row. >>>>>> > >>>>>> > Actually it is one of the valid strategies. >>>>>> > If I understand you well, you want to create: >>>>>> > >>>>>> > - one row per time series generating object (say a thermometer) >>>>>> > - the column names of that row would be a timestamp of time at bay >>>>>> > - the value would be a JSON structure containing the data at bay for >>>>>> > that specific time. >>>>>> > >>>>>> > That is one of the valid approach. But I think we need to support >>>>>> > several: >>>>>> > >>>>>> > - simple column if the data is literally a single element >>>>>> (temperature) >>>>>> > - JSON structure for more complex data per time event >>>>>> > - key pointing to the detailed data somewhere else in the cluster >>>>>> > >>>>>> > The latest would be done in two phases, you load all the keys you >>>>>> are >>>>>> > interested in matching your time range and then do a multiget of >>>>>> sort to >>>>>> > load the data. >>>>>> > >>>>>> > It seems datastax tends to recommend 1 or 2 (denormalization FTW). >>>>>> > >>>>>> > I don't know but there is also the notion of super column which is a >>>>>> > grouping of columns that might also address our composite problem >>>>>> > assuming they can be used for dynamic column families. >>>>>> > >>>>>> > >>>>>> http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra >>>>>> > >>>>>> > >>>>>> http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ >>>>>> > http://www.datastax.com/docs/1.0/ddl/column_family >>>>>> > >>>>>> > > >>>>>> > > An approach we have often taken is to create multiple copies of >>>>>> data in >>>>>> > > different (obviously works well only for immutable objects) or >>>>>> better to >>>>>> > >>>>>> > Yes, that is a feature that I would like OGM to automate for the >>>>>> user. >>>>>> > It declaratively defines the denormalization approaches he wants >>>>>> and the >>>>>> > engine does the persistence. >>>>>> > Next the query engine uses that knowledge to find the best path (or >>>>>> only >>>>>> > possible path in the case of Cassandra :) ) >>>>>> > >>>>>> > > create a table of keys to a main table where in either approach >>>>>> the >>>>>> > > row-keys are effectively a foreign-key and there is column per >>>>>> object >>>>>> > > associated through the foreign-key. Another approach though might >>>>>> be to >>>>>> > use >>>>>> > > a column with type list (or set, or map) to contain keys to the >>>>>> > associated >>>>>> > > objects - this would be a little like the extensions Oracle have >>>>>> for >>>>>> > > mapping 1-* associations, though with the caveat that a column of >>>>>> > > collection type may only contain 64k elements. I wondered if some >>>>>> though >>>>>> > > had been given to this strategy (which I must admit I have not >>>>>> yet used >>>>>> > > myself). >>>>>> > >>>>>> > I am not aware of that approach. >>>>>> > >>>>>> > > >>>>>> > > It seems very likely that different mapping strategies should be >>>>>> > > specifiable, but then I have still to understand how these might >>>>>> fit with >>>>>> > > treiid. >>>>>> > >>>>>> > Forget Teiid for now. We will likely start with the HQL->Walker and >>>>>> do >>>>>> > our own proto query engine before layering Teiid. >>>>>> > >>>>>> > > >>>>>> > > Can I ask about assumptions: is it fair to assume that for >>>>>> Cassandra, OGM >>>>>> > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? >>>>>> This would >>>>>> > > certainly make life simpler. >>>>>> > >>>>>> > Yes that's fine. >>>>>> > >>>>>> > > >>>>>> > > An issue I don't see addressed is the choice of consistency-level >>>>>> (read >>>>>> > or >>>>>> > > write) and I wondered if there was a plan for this? Assumptions >>>>>> can be >>>>>> > made >>>>>> > > on a per table basis, but, certainly for ad hoc queries, it is >>>>>> important >>>>>> > > think to have the flexibility to specify on a per-query basis. >>>>>> > >>>>>> > That's planned. We have an option system that allow for entity / >>>>>> > property overriding of a global setting. While not implemented, we >>>>>> will >>>>>> > also have the ability to override setting per session / query. >>>>>> > That was the plan all along. >>>>>> > >>>>>> > > >>>>>> > > Those are my thoughts so far... I'll see about doing a POC of >>>>>> some of >>>>>> > what >>>>>> > > I have described above >>>>>> > >>>>>> > Thanks :) >>>>>> > >>>>>> > > >>>>>> > > Cheers, >>>>>> > > >>>>>> > > John >>>>>> > > >>>>>> > > >>>>>> > > On Mon, Jul 21, 2014 at 4:48 PM, John Worrell >>>>> > >>>>>> > wrote: >>>>>> > > >>>>>> > > > Hi Emmanuel, >>>>>> > > > >>>>>> > > > I'll take a look at what is there, and I'll get up and running >>>>>> on IRC. >>>>>> > > > >>>>>> > > > I'll particularly look at the time-series issue - non-trivial I >>>>>> think. >>>>>> > > > >>>>>> > > > Cheers, >>>>>> > > > >>>>>> > > > John >>>>>> > > > >>>>>> > > > >>>>>> > > > On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard < >>>>>> > emmanuel at hibernate.org> >>>>>> > > > wrote: >>>>>> > > > >>>>>> > > >> Hi John, >>>>>> > > >> >>>>>> > > >> I thought I had replied to you on Friday but apparently the >>>>>> email >>>>>> > never >>>>>> > > >> went through :/ >>>>>> > > >> >>>>>> > > >> That is good news :) >>>>>> > > >> Jonathan worked on a Cassandra prototype but had to drop due >>>>>> to other >>>>>> > > >> duties. He pushed everything at >>>>>> > > >> >>>>>> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra >>>>>> > > >> >>>>>> > > >> Have a look at what he has done and come ask any question to >>>>>> Gunnar, >>>>>> > > >> Davide or me. There are a bunch of moving pieces. We are >>>>>> mostly on >>>>>> > > >> freenode?s #hibernate-dev ( you need a freenode login >>>>>> > > >> http://freenode.net/faq.shtml#nicksetup ). If you are >>>>>> allergic to >>>>>> > IRC, >>>>>> > > >> let me know and we will find alternatives. >>>>>> > > >> >>>>>> > > >> The most interesting challenge will be to see how we can map >>>>>> time >>>>>> > series >>>>>> > > >> into a collection and make sure we let the user decide how >>>>>> much he >>>>>> > wants to >>>>>> > > >> load. >>>>>> > > >> >>>>>> > > >> Emmanuel >>>>>> > > >> >>>>>> > > >> On 16 Jul 2014, at 13:17, John Worrell >>>>>> wrote: >>>>>> > > >> >>>>>> > > >> > Hi, >>>>>> > > >> > >>>>>> > > >> > I'm interested in contributing to the Cassandra module of >>>>>> > Hibernate-OGM >>>>>> > > >> - >>>>>> > > >> > what would be the baest way to go about this? >>>>>> > > >> > >>>>>> > > >> > Thanks, >>>>>> > > >> > >>>>>> > > >> > John >>>>>> > > >> > _______________________________________________ >>>>>> > > >> > hibernate-dev mailing list >>>>>> > > >> > hibernate-dev at lists.jboss.org >>>>>> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> > > >> >>>>>> > > >> >>>>>> > > > >>>>>> > >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>> >>> >> > From smarlow at redhat.com Fri Sep 12 16:02:06 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 16:02:06 -0400 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... Message-ID: <5413513E.3010105@redhat.com> Hello, How would Hibernate ORM react to its persistence provider class instance being used with multiple application deployments? Is there any "per application" state in the ORM persistence provider class instance? A few different implementations of javax.persistence.spi.PersistenceProviderResolver.getPersistenceProviders() are not caching the returned PersistenceProvider class instances. [1] raised the issue with the WildFly PersistenceProviderResolver.getPersistenceProviders() not caching the provider class instances for reuse. Same question for OGM, is there any "per application state" in the OGM persistence provider class? Scott [1] http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html is the thread which raised this as a performance issue. From smarlow at redhat.com Fri Sep 12 16:39:17 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 16:39:17 -0400 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... In-Reply-To: <5413513E.3010105@redhat.com> References: <5413513E.3010105@redhat.com> Message-ID: <541359F5.4020506@redhat.com> Never mind, we will look at caching the PersistenceProvider class instance at the application deployment level (in WildFly). On 09/12/2014 04:02 PM, Scott Marlow wrote: > Hello, > > How would Hibernate ORM react to its persistence provider class instance > being used with multiple application deployments? Is there any "per > application" state in the ORM persistence provider class instance? > > A few different implementations of > javax.persistence.spi.PersistenceProviderResolver.getPersistenceProviders() > are not caching the returned PersistenceProvider class instances. [1] > raised the issue with the WildFly > PersistenceProviderResolver.getPersistenceProviders() not caching the > provider class instances for reuse. > > Same question for OGM, is there any "per application state" in the OGM > persistence provider class? > > Scott > > [1] > http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html > is the thread which raised this as a performance issue. > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Fri Sep 12 17:02:19 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 17:02:19 -0400 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... In-Reply-To: <541359F5.4020506@redhat.com> References: <5413513E.3010105@redhat.com> <541359F5.4020506@redhat.com> Message-ID: <54135F5B.6070607@redhat.com> What triggers Hibernate Validator to call PersistenceProviderResolver.getPersistenceProviders()? Does this happen during the call to PersistenceProvider.createContainerEntityManagerFactory() or later after application deployment completes? I'm looking at changing PersistenceProviderResolver.getPersistenceProviders() to cache the results on a per deployment basis but need to know when the first call will be made, so I don't break deployment of persistence providers in the deployed application. From smarlow at redhat.com Mon Sep 15 18:47:09 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 15 Sep 2014 18:47:09 -0400 Subject: [hibernate-dev] DuplicateMappingException in ORM 4.3.6.Final Message-ID: <54176C6D.7070206@redhat.com> I'm working on an application server bug fix that I need some advice with, as Hibernate ORM 4.3.6.Final is throwing a "o.h.DuplicateMappingException: Duplicate query mapping EventManager.MyEvents" after I fixed a jar-file reference bug in WildFly (when I try to deploy a test case). Prior to my jar-file bug fix, the jar-file URL was incorrectly pointing at the wrong location (zero files were returned when file url was accessed). As a result, entities were loaded only once from the ear/lib jar. Now, with my bug fix (getJarFileUrls now returns a valid URL for jar-file) , WildFly is getting the DuplicateMappingException because the entity is loaded twice (even though *exclude-unlisted-classes* is in the persistence unit). I would like to resolve the DME before back porting the "jar-file" (WildFly) bug fix. I didn't see this behaviour in my ORM 4.2.x testing (with EAP). By the way, the getPersistenceUnitRootUrl is the test.ear. test.ear contents: lib test-entities.jar META-INF application.xml MANIFEST.MF persistence.xml test-ejb.jar persistence.xml contents: lib/test-entities.jar test-entities.jar contents: META-INF Event.hbm.xml EventManager entity class Event entity class Event.hbm.xml contents: SELECT * FROM EVENT e where e.manager = ? Thanks, Scott From smarlow at redhat.com Tue Sep 16 06:50:50 2014 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 16 Sep 2014 06:50:50 -0400 (EDT) Subject: [hibernate-dev] =?utf-8?q?DuplicateMappingException_in_ORM_4=2E3?= =?utf-8?q?=2E6=2EFinal?= Message-ID: <1546271455.23275446.1410864650982.JavaMail.zimbra@zmail12.collab.prod.int.phx2.redhat.com> If the cause is allowing the application to deploy with the persistence unit root being the entire EAR, I am interested in feedback on what to do. e.g. throw a deployment exception or log a warning. Logging a warning is probably best, if this is indeed the cause. It might be harsh to fail the deployment, when it might work (if no jar-files are specified). From hardy at hibernate.org Tue Sep 16 08:27:26 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 16 Sep 2014 14:27:26 +0200 Subject: [hibernate-dev] Projecting an index In-Reply-To: References: <93E4F159-0F7A-42C2-BF16-D6B915FAEB5C@hibernate.org> <20140905152733.GB32249@Sarmakand-2.local> Message-ID: Hi Marc, sorry for the late reply. I forgot to answer :-( On 5 Jan 2014, at 19:11, Marc Schipperheyn wrote: > Current situation > * Loading Wallposts directly from Lucene index. > * Posts references properties that change relatively often or have cascading indexing impact if they would be saved within the Post document, e.g. User (photo, name, title, link), Classified (photo, title, decription), Group (photo, title, description), Comments (User, user.name, user.link) > * Posts, Classifieds and Groups can be "Liked", which requires per user post processing because we want to show people liking stuff that are close to you > * Of groups you can be a member or not so, it also requires post processing on a per user basis > * In addition, some of these related objects have specific properties such as Event => eventDate, RSVP > > So, right now, we're optimizing this post processing process so that the impact is as low as possible. However, because all of these related objects are stored in different indexes it requires multiple hits against the index which has an impact on performance. > > Desired situation > Since a lot of these related objects have common properties: photo, link, title, description and in this case of the Post display purposes we only need a small subset of the properties, it would be desirable to be able to query a single index in a one pass retrieval querying for (object type - id). Got you. > The idea of combining all these objects into a single index somehow feels wrong Why? I would for example assume that in the case of an application using Lucene directly, that there is often just one single index. I agree that it feels natural in Hibernate Search to separate indexes per entity, but sharing an index in your use case seems reasonable as well. Of course you get a bigger index size which might effect search performance, but on the other hand you now ply target a single index, instead of multiple. This might even outweigh any performance penalty you get for having a single index. > and since I don't have any experience doing this, it's hard to oversee the impact of this, including potential bugs because this is not a common use case. Sure, the only way to know for sure is to actually try and run performance tests. A lot of the required changes would be on a configuration level, so it might not bee too hard to give it a go. > If I would be able to create a limited "combined secondary index" that would actually meet my use case. > > So, this brought me to my original question: can I project properties to a separate index. Which, given my new understanding of combining entities into a single index can also be read as: > "Can I create two indexes based on a single entity, targeting only a subset of properties, basically duplicating index content?. The answer to this particular question is no. I don?t think this would also not be so easy to achieve with the current design of the Search codebase. You would somehow need new/additional configuration options and in the engine itself we probably would have to do a fair bit of shuffling to make it work. ?Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20140916/9f072bfa/attachment.bin From steve at hibernate.org Tue Sep 16 15:32:15 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 16 Sep 2014 14:32:15 -0500 Subject: [hibernate-dev] DuplicateMappingException in ORM 4.3.6.Final In-Reply-To: <1546271455.23275446.1410864650982.JavaMail.zimbra@zmail12.collab.prod.int.phx2.redhat.com> References: <1546271455.23275446.1410864650982.JavaMail.zimbra@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: exclude-unlisted-classes has no impact on hbm.xml discovery On Tue, Sep 16, 2014 at 5:50 AM, Scott Marlow wrote: > If the cause is allowing the application to deploy with the persistence > unit root being the entire EAR, I am interested in feedback on what to do. > e.g. throw a deployment exception or log a warning. Logging a warning is > probably best, if this is indeed the cause. It might be harsh to fail the > deployment, when it might work (if no jar-files are specified). > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Wed Sep 17 05:22:34 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 17 Sep 2014 11:22:34 +0200 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... In-Reply-To: <54135F5B.6070607@redhat.com> References: <5413513E.3010105@redhat.com> <541359F5.4020506@redhat.com> <54135F5B.6070607@redhat.com> Message-ID: <20140917092234.GQ24677@hibernate.org> PersistenceProvider implementations are not app specific. Hibernate Validator uses Persistence.getPersistenceUtil() This in turn is a static reference object that in its method calls Persistence.getProviders() *each time* to resolve operations like isLoaded(entity). So to answer your question, I think it's after. On Fri 2014-09-12 17:02, Scott Marlow wrote: > What triggers Hibernate Validator to call > PersistenceProviderResolver.getPersistenceProviders()? Does this happen > during the call to > PersistenceProvider.createContainerEntityManagerFactory() or later after > application deployment completes? > > I'm looking at changing > PersistenceProviderResolver.getPersistenceProviders() to cache the > results on a per deployment basis but need to know when the first call > will be made, so I don't break deployment of persistence providers in > the deployed application. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Wed Sep 17 05:28:07 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 17 Sep 2014 11:28:07 +0200 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... In-Reply-To: <20140917092234.GQ24677@hibernate.org> References: <5413513E.3010105@redhat.com> <541359F5.4020506@redhat.com> <54135F5B.6070607@redhat.com> <20140917092234.GQ24677@hibernate.org> Message-ID: <20140917092807.GR24677@hibernate.org> BTW there can be multiple persistence units deployed per application so if you are trying to tie your cache to the lifecycle of createContainerEntityManagerFactory, you might be making a mistake. On Wed 2014-09-17 11:22, Emmanuel Bernard wrote: > PersistenceProvider implementations are not app specific. > > Hibernate Validator uses > > Persistence.getPersistenceUtil() > > This in turn is a static reference object that in its method calls > Persistence.getProviders() *each time* to resolve operations like > isLoaded(entity). > > So to answer your question, I think it's after. > > On Fri 2014-09-12 17:02, Scott Marlow wrote: > > What triggers Hibernate Validator to call > > PersistenceProviderResolver.getPersistenceProviders()? Does this happen > > during the call to > > PersistenceProvider.createContainerEntityManagerFactory() or later after > > application deployment completes? > > > > I'm looking at changing > > PersistenceProviderResolver.getPersistenceProviders() to cache the > > results on a per deployment basis but need to know when the first call > > will be made, so I don't break deployment of persistence providers in > > the deployed application. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Wed Sep 17 11:32:03 2014 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 17 Sep 2014 16:32:03 +0100 Subject: [hibernate-dev] Embedded value not null when it includes an @ElementCollection Message-ID: Hi, I've created a test for OGM where we store an @Embeddable containing a list annotated with @ElementCollection [1]: This is the embedded: @Embeddable public class PhoneNumber { private String main; @ElementCollection private List alternatives; ... } In the test [2] I first save an entity with the embedded attribute set to null and then I call a session.get(...) to obtain it. The embedded attribute is not null as I was expecting. The same this happend when I've tried it on ORM, is this the expected behaviour? Thanks, Davide [1] https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java [2] https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195 From daltodavide at gmail.com Wed Sep 17 11:31:13 2014 From: daltodavide at gmail.com (Davide D'Alto) Date: Wed, 17 Sep 2014 16:31:13 +0100 Subject: [hibernate-dev] Embedded value not null when it includes an @ElementCollection Message-ID: Hi, I've created a test for OGM where we store an @Embeddable containing a list annotated with @ElementCollection [1]: This is the embedded: @Embeddable public class PhoneNumber { private String main; @ElementCollection private List alternatives; ... } In the test [2] I first save an entity with the embedded attribute set to null and then I call a session.get(...) to obtain it. The embedded attribute is not null as I was expecting. The same this happend when I've tried it on ORM, is this the expected behaviour? Thanks, Davide [1] https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java [2] https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195 From steve at hibernate.org Thu Sep 18 10:15:58 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 18 Sep 2014 09:15:58 -0500 Subject: [hibernate-dev] Embedded value not null when it includes an @ElementCollection In-Reply-To: References: Message-ID: I have not played with case specifically, but it makes sense. ORM tries hard to never return a null collection reference. On Wed, Sep 17, 2014 at 10:31 AM, Davide D'Alto wrote: > Hi, > I've created a test for OGM where we store an @Embeddable containing a list > annotated with @ElementCollection [1]: > > This is the embedded: > > @Embeddable > public class PhoneNumber { > > private String main; > > @ElementCollection > private List alternatives; > > ... > > } > > In the test [2] I first save an entity with the embedded attribute set to > null and then I call a session.get(...) to obtain it. The embedded > attribute is not null as I was expecting. > > The same this happend when I've tried it on ORM, is this the expected > behaviour? > > Thanks, > Davide > > [1] > > https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java > > [2] > > https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From davide at hibernate.org Thu Sep 18 10:38:58 2014 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 18 Sep 2014 15:38:58 +0100 Subject: [hibernate-dev] Embedded value not null when it includes an @ElementCollection In-Reply-To: References: Message-ID: Thanks, Davide On Thu, Sep 18, 2014 at 3:15 PM, Steve Ebersole wrote: > I have not played with case specifically, but it makes sense. ORM tries > hard to never return a null collection reference. > > On Wed, Sep 17, 2014 at 10:31 AM, Davide D'Alto > wrote: > >> Hi, >> I've created a test for OGM where we store an @Embeddable containing a >> list >> annotated with @ElementCollection [1]: >> >> This is the embedded: >> >> @Embeddable >> public class PhoneNumber { >> >> private String main; >> >> @ElementCollection >> private List alternatives; >> >> ... >> >> } >> >> In the test [2] I first save an entity with the embedded attribute set to >> null and then I call a session.get(...) to obtain it. The embedded >> attribute is not null as I was expecting. >> >> The same this happend when I've tried it on ORM, is this the expected >> behaviour? >> >> Thanks, >> Davide >> >> [1] >> >> https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java >> >> [2] >> >> https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From andrea at hibernate.org Thu Sep 18 10:44:51 2014 From: andrea at hibernate.org (andrea boriero) Date: Thu, 18 Sep 2014 15:44:51 +0100 Subject: [hibernate-dev] Patch to ORM 4.2 Message-ID: I have applied the patch for the jira https://hibernate.atlassian.net/browse/HHH-9369 to the following branches: - master - 4.3 do I have to apply it also to 4.2? Thanks, Andrea From steve at hibernate.org Thu Sep 18 10:52:37 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 18 Sep 2014 09:52:37 -0500 Subject: [hibernate-dev] Patch to ORM 4.2 In-Reply-To: References: Message-ID: Generally speaking we do not port changes to the 4.2 branch anymore. However this one is a pretty obvious bug. I would say that as long as no public contracts were changed, to go ahead and port it. But I would check/coordinate with Gail. Gail, wdyt? On Thu, Sep 18, 2014 at 9:44 AM, andrea boriero wrote: > I have applied the patch for the jira > https://hibernate.atlassian.net/browse/HHH-9369 to the following > branches: > - master > - 4.3 > > do I have to apply it also to 4.2? > > Thanks, > > Andrea > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 18 11:26:06 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 18 Sep 2014 10:26:06 -0500 Subject: [hibernate-dev] Jira + GitHub Message-ID: Have not not had a chance to look deeply yet, but interesting... https://confluence.atlassian.com/display/AOD/Advanced+workflow+configuration?utm_campaign=yuX3vawa&utm_medium=navbar&utm_source=inproduct From sanne at hibernate.org Fri Sep 19 05:08:10 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 19 Sep 2014 10:08:10 +0100 Subject: [hibernate-dev] Hibernate OGM connecting to JDG's version of Infinispan Message-ID: Hi all, I didn't try this but I'm wondering if I could use Hibernate OGM with its Infinispan backend to deploy on JBoss EAP6 and use the Infinispan build from JDG 6. Could you make sure this is possible? I'm expecting some trouble by the fact that depending on Hibernate *ORM* implicitly or explicitly this will bring along the classpath visibility of the EAP version of Infinispan (which is not the one we'd want to use). For example simply by deploying a JPA based application, we'd get this version of Infinispan as it's exposed to the application so that it could be used as a 2nd level cache implementation. To clarify: the JDG distribution is packaged as a set of JBoss Modules so you can "layer" them on top of EAP without replacing the Infinispan & co jars included by the applications server for internal purposes like session clustering and Hibernate caching. OGM is for me just one possible case, ultimately we need to make sure that people using Hibernate can use alternative versions of Infinispan as well, and not be locked into a specific version by the simple fact of using JPA: I'm having the same nasty problem with Search: unable to use JDG for index storage. Sanne From gunnar at hibernate.org Fri Sep 19 05:43:23 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 19 Sep 2014 11:43:23 +0200 Subject: [hibernate-dev] Hibernate OGM connecting to JDG's version of Infinispan In-Reply-To: References: Message-ID: Hi, 2014-09-19 11:08 GMT+02:00 Sanne Grinovero : > Hi all, > > I didn't try this but I'm wondering if I could use Hibernate OGM with > its Infinispan backend to deploy on JBoss EAP6 and use the Infinispan > build from JDG 6. > > Could you make sure this is possible? > That's an interesting question, I've filed https://hibernate.atlassian.net/browse/OGM-604 for tracking this requirement. > > I'm expecting some trouble by the fact that depending on Hibernate > *ORM* implicitly or explicitly this will bring along the classpath > visibility of the EAP version of Infinispan (which is not the one we'd > want to use). > > For example simply by deploying a JPA based application, we'd get this > version of Infinispan as it's exposed to the application so that it > could be used as a 2nd level cache implementation. > I just had a quick look at the OGM module descriptors we create for EAP and WildFly. To my surprise, we bundle Infinispan ourselves for EAP (it's part of the OGM core module), whereas we depend on the provided module in WildFly. Extracting a separate hibernate-ogm-module (as we have it for all other dialects) would be the first step IMO to improve the situation. We then could create yet another module which depends on the modules provided by the JDG distribution you mention below (the dialect would be the same as for ISPN, only the module dependencies would differ). Users would enable one or the other dialect module for the application. About the conflict with the ISPN version exposed by ORM you mention, is this always the case or only when enabling 2nd-level caching? I would hope for the latter. To clarify: the JDG distribution is packaged as a set of JBoss Modules > so you can "layer" them on top of EAP without replacing the Infinispan > & co jars included by the applications server for internal purposes > like session clustering and Hibernate caching. > Can one get that distribution e.g. as Maven dependency? > > OGM is for me just one possible case, ultimately we need to make sure > that people using Hibernate can use alternative versions of Infinispan > as well, and not be locked into a specific version by the simple fact > of using JPA: I'm having the same nasty problem with Search: unable to > use JDG for index storage. > > Sanne > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Fri Sep 19 16:54:50 2014 From: gbadner at redhat.com (Gail Badner) Date: Fri, 19 Sep 2014 16:54:50 -0400 (EDT) Subject: [hibernate-dev] Patch to ORM 4.2 In-Reply-To: References: Message-ID: <1740942396.7408825.1411160090813.JavaMail.zimbra@redhat.com> I agree this is clearly a bug, doesn't change any contracts, and is easily fixed. I went ahead and cherry-picked it. I had to make a very minor fix because SimpleValue.columns is type List (not List). I've pushed the fix to 4.2 to be fixed in 4.2.16. Thanks Andrea! Gail ----- Original Message ----- > From: "Steve Ebersole" > To: "andrea boriero" > Cc: "Hibernate Dev" > Sent: Thursday, September 18, 2014 7:52:37 AM > Subject: Re: [hibernate-dev] Patch to ORM 4.2 > > Generally speaking we do not port changes to the 4.2 branch anymore. > However this one is a pretty obvious bug. I would say that as long as no > public contracts were changed, to go ahead and port it. But I would > check/coordinate with Gail. > > Gail, wdyt? > > On Thu, Sep 18, 2014 at 9:44 AM, andrea boriero > wrote: > > > I have applied the patch for the jira > > https://hibernate.atlassian.net/browse/HHH-9369 to the following > > branches: > > - master > > - 4.3 > > > > do I have to apply it also to 4.2? > > > > Thanks, > > > > Andrea > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Sun Sep 21 17:39:47 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 21 Sep 2014 22:39:47 +0100 Subject: [hibernate-dev] Hibernate OGM connecting to JDG's version of Infinispan In-Reply-To: References: Message-ID: On 19 September 2014 10:43, Gunnar Morling wrote: > Hi, > > 2014-09-19 11:08 GMT+02:00 Sanne Grinovero : >> >> Hi all, >> >> I didn't try this but I'm wondering if I could use Hibernate OGM with >> its Infinispan backend to deploy on JBoss EAP6 and use the Infinispan >> build from JDG 6. >> >> Could you make sure this is possible? > > > That's an interesting question, I've filed > https://hibernate.atlassian.net/browse/OGM-604 for tracking this > requirement. Thanks >> >> >> I'm expecting some trouble by the fact that depending on Hibernate >> *ORM* implicitly or explicitly this will bring along the classpath >> visibility of the EAP version of Infinispan (which is not the one we'd >> want to use). >> >> For example simply by deploying a JPA based application, we'd get this >> version of Infinispan as it's exposed to the application so that it >> could be used as a 2nd level cache implementation. > > > I just had a quick look at the OGM module descriptors we create for EAP and > WildFly. To my surprise, we bundle Infinispan ourselves for EAP (it's part > of the OGM core module), whereas we depend on the provided module in > WildFly. I guess OGM is aiming at compatibility with the Infinispan version bundled in Wildfly, so when running on WildFly the provided version is fine, while on EAP we need to override the system's Infinispan version. But this assumes a specific version of WildFly: that was easy enough when there was only one release but with WildFly 9 coming we might need modules on it too (depending on the version). Generally speaking I think we shouldn't bundle our own Infinispan jars but try to have it download and reuse the modules built and released by the Infinispan project (since recently they follow our same strategy, so there will be a modules set available for each version of Infinispan we need). > > Extracting a separate hibernate-ogm-module (as we have it for all other > dialects) would be the first step IMO to improve the situation. We then > could create yet another module which depends on the modules provided by the > JDG distribution you mention below (the dialect would be the same as for > ISPN, only the module dependencies would differ). Users would enable one or > the other dialect module for the application. That's where it gets a bit fishy. I don't like it that we have to duplicate the dialect module, even though the code is the same. An alternative but equally ugly solution would be the user to edit the modules.xml to change the slots as he wishes, but I don't think it's a good idea to have a "well known" module ID changed depending on need, it's not supposed to be a configuration file. An alternative approach would be that the user's app had to bundle the grid-dialect jar with the application, this way the dialect would be exposed to the same modules as defined by the user in its own deployer descriptor, and has an opportunity to specify the slot directly.. but that's not clean either :-/ Maybe we could use aliases, and our modules depend on a module identifier which has to be created by the user. But then that would be a system-wide decision, while the point of modules it to make it possible for different applications to evolve independently... I don't know the solution, probably best to discuss this with the WildFly team. > > About the conflict with the ISPN version exposed by ORM you mention, is this > always the case or only when enabling 2nd-level caching? I would hope for > the latter. Ok so I thought it was always the case, but it turns out my failures where caused by a different and much simpler problem :) What actually happens is that Infinispan isn't exposed to the application using ORM after all, but it is exposed to ORM itself so that it can eventually load its components via SPIs. I fear that - depending on how OGM is booting exactly - some of its components might be loaded from this same context, so exposing the ORM module classloader which does have access to Infinispan slot "wrong". I guess the good news is that we're in control of such situations, but it needs extensive testing to make sure we always use the correct classloaders in both OGM and ORM codebase for this purpose. >> To clarify: the JDG distribution is packaged as a set of JBoss Modules >> so you can "layer" them on top of EAP without replacing the Infinispan >> & co jars included by the applications server for internal purposes >> like session clustering and Hibernate caching. > > > Can one get that distribution e.g. as Maven dependency? Yes but not in a convenient way for CI to access it automatically: you have to download the tarball of the whole Maven repository from the Red Hat support portal: - https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=31673&product=data.grid&version=6.3.0&downloadType=distributions Which requires a login to accept T&C .. but we can of course download it once and unzip on the ci servers. Cheers, Sanne >> >> >> OGM is for me just one possible case, ultimately we need to make sure >> that people using Hibernate can use alternative versions of Infinispan >> as well, and not be locked into a specific version by the simple fact >> of using JPA: I'm having the same nasty problem with Search: unable to >> use JDG for index storage. >> >> Sanne > > > --Gunnar > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From amits.84 at gmail.com Mon Sep 22 00:56:18 2014 From: amits.84 at gmail.com (amit shah) Date: Mon, 22 Sep 2014 10:26:18 +0530 Subject: [hibernate-dev] Performance issue blocking upgrade to hibernate 4.3.5 Message-ID: Hello, We have been blocked by a performance degradation issue logged as HHH-9396 . Since there has been no response on jira, I would like to ask on this dev forum on the further plan. Kindly have a look and respond. Thanks, Amit. From sanne at hibernate.org Mon Sep 22 05:15:38 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 22 Sep 2014 10:15:38 +0100 Subject: [hibernate-dev] Performance issue blocking upgrade to hibernate 4.3.5 In-Reply-To: References: Message-ID: Hi Amit, I don't have an Oracle database ready to run a performance test, others on this list might have one but it seems you have one ready for sure ;-) Could you try identify what is causing this regression? That would be very helpful, especially as this *might* be strictly related to your environment: please consider that these latest versions include significant performance improvement patches (and are significantly more efficient in *our* tests), and this might be stressing your database / connection pool / network to the point you need to renew your tuning of external parameters (for example setting a larger connection pool). If you find the reason, I'll be very happy to look into it and get it fixed. -- Sanne On 22 September 2014 05:56, amit shah wrote: > Hello, > > We have been blocked by a performance degradation issue logged as HHH-9396 > . Since there has been no > response on jira, I would like to ask on this dev forum on the further plan. > > Kindly have a look and respond. > > Thanks, > Amit. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From amits.84 at gmail.com Mon Sep 22 08:42:10 2014 From: amits.84 at gmail.com (amit shah) Date: Mon, 22 Sep 2014 18:12:10 +0530 Subject: [hibernate-dev] Performance issue blocking upgrade to hibernate 4.3.5 In-Reply-To: References: Message-ID: Ok. I will use version 4.3.6 and attach a profiler to get the internal details. Thanks, Amit. On Mon, Sep 22, 2014 at 2:45 PM, Sanne Grinovero wrote: > Hi Amit, > I don't have an Oracle database ready to run a performance test, > others on this list might have one but it seems you have one ready for > sure ;-) > Could you try identify what is causing this regression? That would be > very helpful, especially as this *might* be strictly related to your > environment: > please consider that these latest versions include significant > performance improvement patches (and are significantly more efficient > in *our* tests), and this might be stressing your database / > connection pool / network to the point you need to renew your tuning > of external parameters (for example setting a larger connection pool). > > If you find the reason, I'll be very happy to look into it and get it > fixed. > > -- Sanne > > On 22 September 2014 05:56, amit shah wrote: > > Hello, > > > > We have been blocked by a performance degradation issue logged as > HHH-9396 > > . Since there has been > no > > response on jira, I would like to ask on this dev forum on the further > plan. > > > > Kindly have a look and respond. > > > > Thanks, > > Amit. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Thu Sep 25 14:39:05 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 25 Sep 2014 20:39:05 +0200 Subject: [hibernate-dev] [ORM] save vs persist for POST_INSERT generators Message-ID: <20140925183905.GA49637@hibernate.org> Hi Steve, I've got a quick question. I sort of remember that we were delaying `persist()` operations - until flush I suppose. This is something we could not do to `save()` because `persist()` does not force us to return the id while save does. I am in particular considering the case where the generator is of type POST_INSERT like a column identifier. While browsing the code I could not spot any different between the handing of a save event and a persist event and the actual SQL executoin seems to happen duing the `persist()` call as opposed to `flush()`. Is it that I have dreamt it all? Or did we used to do that but not anymore? Emmanuel From smarlow at redhat.com Thu Sep 25 15:01:56 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 25 Sep 2014 15:01:56 -0400 Subject: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployments to share ... In-Reply-To: <20140917092807.GR24677@hibernate.org> References: <5413513E.3010105@redhat.com> <541359F5.4020506@redhat.com> <54135F5B.6070607@redhat.com> <20140917092234.GQ24677@hibernate.org> <20140917092807.GR24677@hibernate.org> Message-ID: <542466A4.8020806@redhat.com> On 09/17/2014 05:28 AM, Emmanuel Bernard wrote: > BTW there can be multiple persistence units deployed per application so > if you are trying to tie your cache to the lifecycle of > createContainerEntityManagerFactory, you might be making a mistake. When applications include a persistence provider(s), we associate the provider with the application classloader (saved in PersistenceProviderResolver level cache). This is not tied to the persistence unit. The call to PersistenceProvider.createContainerEntityManagerFactory() can happen before the PersistenceProviderResolver cache is updated with the deployed provider. So, it is important to understand when Hibernate Validator first calls Persistence.getProviders(), so that we know to set the cache earlier. This looked hard to do a few years ago (chicken + egg problem with when application classloaders are known in WildFly from what I remember). > > On Wed 2014-09-17 11:22, Emmanuel Bernard wrote: >> PersistenceProvider implementations are not app specific. >> >> Hibernate Validator uses >> >> Persistence.getPersistenceUtil() >> >> This in turn is a static reference object that in its method calls >> Persistence.getProviders() *each time* to resolve operations like >> isLoaded(entity). >> >> So to answer your question, I think it's after. >> >> On Fri 2014-09-12 17:02, Scott Marlow wrote: >>> What triggers Hibernate Validator to call >>> PersistenceProviderResolver.getPersistenceProviders()? Does this happen >>> during the call to >>> PersistenceProvider.createContainerEntityManagerFactory() or later after >>> application deployment completes? >>> >>> I'm looking at changing >>> PersistenceProviderResolver.getPersistenceProviders() to cache the >>> results on a per deployment basis but need to know when the first call >>> will be made, so I don't break deployment of persistence providers in >>> the deployed application. >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From oskar.berggren at gmail.com Fri Sep 26 12:00:21 2014 From: oskar.berggren at gmail.com (Oskar Berggren) Date: Fri, 26 Sep 2014 18:00:21 +0200 Subject: [hibernate-dev] What about HHH-2564 StatelessSession query uniquing is inconsistent? Message-ID: Hi, According to https://hibernate.atlassian.net/browse/HHH-2564 a stateless session may in some circumstances return multiple instances representing the same entity. As noted in the report, this seems to contradict the initial intention of stateless session, as described in HHh-742. The issue has been open with no comments since 2007. What is your take on this problem? Is it a bug that should be fixed, or is the present behavior really as intended? /Oskar From emmanuel at hibernate.org Mon Sep 29 12:16:38 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 29 Sep 2014 18:16:38 +0200 Subject: [hibernate-dev] [OGM] Removing row keys from associations In-Reply-To: References: Message-ID: <20140929161638.GA51558@hibernate.org> I think that can happen due to the weak transactional guarantees the underlying backend provides. Why do you ask? (that is if you remember as this email is quite old - nothing like being stuck on a place for 12 hours to catch up ;) ). On Wed 2014-08-27 22:40, Gunnar Morling wrote: > Hi Emmanuel, > > Is there any legitimate case where Association#remove(RowKey) is invoked > for a key which is not present in that specific association instance? Or > would this indicate some programming error? > > Thanks, > > --Gunnar From gunnar at hibernate.org Tue Sep 30 03:10:44 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 30 Sep 2014 09:10:44 +0200 Subject: [hibernate-dev] [OGM] Removing row keys from associations In-Reply-To: <20140929161638.GA51558@hibernate.org> References: <20140929161638.GA51558@hibernate.org> Message-ID: Thanks for coming back on this :) 2014-09-29 18:16 GMT+02:00 Emmanuel Bernard : > I think that can happen due to the weak transactional guarantees the > underlying backend provides. > Why do you ask? (that is if you remember as this email is quite old - > nothing like being stuck on a place for 12 hours to catch up ;) ). > I'm not entirely sure anymore why I asked :) Maybe I considered to guard against it using an assertion. Does it really depend on the capabilities of the store, though? Between loading an Association and removing a RowKey from it, all is in our control (and all in one thread). So if we invoke Association#remove() for a RowKey which isn't present in the loaded Association object, it still seems fishy to me. Note that's different from trying to remove an association row in the store actually, there it may be gone already of course. On Wed 2014-08-27 22:40, Gunnar Morling wrote: > > Hi Emmanuel, > > > > Is there any legitimate case where Association#remove(RowKey) is invoked > > for a key which is not present in that specific association instance? Or > > would this indicate some programming error? > > > > Thanks, > > > > --Gunnar >