[hibernate-dev] [OGM] When is AssociationKey serialized?
Hi, I'm wondering why org.hibernate.ogm.grid.AssociationKey implements Serializable. When is it actually serialized? I'm suspecting the answer is "never", as the type of the "metadata" member is not serializable, so I'd expect a NotSerializableException to be raised. If so, does anything speak against making AssociationKey not implement Serializable? Thanks, --Gunnar ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
If you store anything in Infinispan, it should at the very least be Serializable. A better solution would be to provide custom Externalizers: https://hibernate.atlassian.net/browse/OGM-37 On 3 February 2014 10:56, Gunnar Morling wrote: > Hi, > > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements > Serializable. When is it actually serialized? When you use Infinispan in clustered mode. > > I'm suspecting the answer is "never", as the type of the "metadata" member > is not serializable, so I'd expect a NotSerializableException to be raised. Our problem is probably that we don't have integration tests using Infinispan in modes other than "Local". I suspect I avoided making them as they make the testsuite slower, but it seems you just highlighted an important reason to add them :-/ > > If so, does anything speak against making AssociationKey not implement > Serializable? It's needed. Also I think it's an important "warning flag" in terms of design: never consider hooking references to services in such a key, and strive to keep it as a very simple value holder. -- Sanne > > Thanks, > > --Gunnar > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
2014/2/3 Sanne Grinovero > If you store anything in Infinispan, it should at the very least be > Serializable. > > A better solution would be to provide custom Externalizers: > https://hibernate.atlassian.net/browse/OGM-37 Ah, I see. I like the Externalizer approach as I found it surprising that AK implements Serializable as there apparently is no need for it from the perspective of the core engine itself. > > > On 3 February 2014 10:56, Gunnar Morling wrote: > > Hi, > > > > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements > > Serializable. When is it actually serialized? > > When you use Infinispan in clustered mode. > > > > > I'm suspecting the answer is "never", as the type of the "metadata" > member > > is not serializable, so I'd expect a NotSerializableException to be > raised. > > Our problem is probably that we don't have integration tests using > Infinispan in modes other than "Local". > I suspect I avoided making them as they make the testsuite slower, but > it seems you just highlighted an important reason to add them :-/ Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for adding a test for this scenario. I'm still wondering how it supposed to work given that AssociationKey contains a non-serializable non-transient member. > > > > If so, does anything speak against making AssociationKey not implement > > Serializable? > > It's needed. Also I think it's an important "warning flag" in terms of > design: never consider hooking references to services in such a key, > and strive to keep it as a very simple value holder. > Hum, not sure whether making a type Serializable is the right way to indicate such a matter. But of course the requirement stands as is for Infinispan as you describe, at least unless that Externalizer-based approach gets implemented. Thanks for the clarification, --Gunnar > > -- Sanne > > > > > Thanks, > > > > --Gunnar > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM
2014/1/21 Sanne Grinovero > On 21 January 2014 13:25, Gunnar Morling wrote: > > 2014/1/21 Sanne Grinovero > >> > >> I don't know if that's explicitly defined in the spec, but even if it > >> wasn't I wouldn't be happy as a user to see an exception for such a > commonly > >> used feature. > > > > So you prefer to silently use another strategy than the one configured > > instead of reporting the issue? Wouldn't rather a user work with AUTO if > she > > wanted the engine to choose a strategy? > > Confused. I'm stating the opposite: if the user is explicitly > demanding IDENTITY strategy, we should not override that. > Ok, then we're on the same page. But overriding is what actually happens today, since OgmIdentityGenerator just delegates to OgmTableGenerator. > Otherwise he/she should definitely use AUTO. > Right. > > > > > Do you know how ORM handles the case of using IDENTITY on stores which > don't > > support it? > > Sure, you get an exception. You don't have to implement it from a spec > perspective, I'm just saying it's nice to have and makes a lot of > sense for practical needs to support Longs rather than UUIDs. > What I mean is, MongoDB and CouchDB can assign an id themselves when inserting a record without passing in an id. This id is a UUID for these stores. I think it would make sense to leverage that functionality on these stores if IDENTITY is configured. Otherwise (a store doesn't provide such functionality) an exception should be raised. > > >> > >> Clearly when such an ID is requested we need to invoke the server out of > >> the batching / transaction context, which might be a suboptimal > strategy but > >> exactly what the user is asking for:theyr choice of they want to > tradeoff > >> simplicity for performance. > > > > I'm not quite following. Using TABLE behavior instead of IDENTITY doesn't > > seem like doing what the user has asked for? > > Agree, and confused too. I didn't know we where actually using TABLE, > although in our "databases" the difference might be unclear in some > cases? > Agreed, the difference may be blurry, but I think mapping the IDENTITY strategy to a store's capability to create ids "inline" when inserting a document is feasible and would help avoiding some round trips to the store. > >> > >> Also to keep in mind for the Infinispan case the current approach is > very > >> slow but now that we've upgraded to latest wildfly there's a new feature > >> could use to optimise for this: COUNTER protocol in JGroups combined > with > >> FORK channels. > > > > That's interesting, do you have a pointer with more information on that? > > - > http://belaban.blogspot.co.uk/2013/08/how-to-hijack-jgroups-channel-inside.html > - https://raw.github.com/belaban/JGroups/master/doc/design/FORK.txt > > The docs specifically make the COUNTER example, as that's what I had > in mind when we designed the new protocols ;-) > We created this _because of_ the OGM needs. > I see. Would be nice if you could file a JIRA issue with some more details if you find some time, so the idea gets a bit more clear. > Sanne > > > > >> > >> Sanne > >> > >> On 20 Jan 2014 16:42, "Gunnar Morling" wrote: > >>> > >>> Ah, is that specified somewhere? I couldn't find anything in the spec > >>> from > >>> a quick look. > >>> > >>> > >>> 2014/1/20 Emmanuel Bernard > >>> > >>> > The problem is that in JPA, IDENTITY returns a long, not a UUID. > >>> > > >>> > On Mon 2014-01-20 12:23, Gunnar Morling wrote: > >>> > > Hi, > >>> > > > >>> > > While reviewing the PR for batch operations in OGM [1], I took some > >>> > > time > >>> > to > >>> > > better understand OGM's approaches for id generation. > >>> > > > >>> > > Now I'm wondering about how GenerationType.IDENTITY is implemented. > >>> > > The > >>> > > corresponding generator (OgmIdentityGenerator) just delegates to a > >>> > > table-based strategy, so an id is always pre-allocated and then > >>> > > passed > >>> > into > >>> > > the dialect when creating a tuple. > >>> > > > >>> > > I think it would be nice to have proper support for > server-generated > >>> > > ids, > >>> > > in particular since some stores return the inserted id directly > from > >>> > > the > >>> > > insert operation, i.e. without requiring another read. > >>> > > > >>> > > For the time being, as the current implementation doesn't really > >>> > > adhere > >>> > to > >>> > > the semantics of GenerationType.IDENTITY, should we raise an error > >>> > > when > >>> > > using it instead of silently using another strategy? > >>> > > > >>> > > Thoughts? > >>> > > > >>> > > --Gunnar > >>> > > > >>> > > [1] https://hibernate.atlassian.net/browse/OGM-175 > >>> > > ___ > >>> > > hibernate-dev mailing list > >>> > > hibernate-dev@lists.jboss.org > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > > >>> ___ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>>
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
Hum, with the fact that this object now points to metadata, I wonder if we should force EhCache, Map and Infinispan to have their own version of EntityKey / RowKey and AssociationKey (or an appropriate externalizer). Emmanuel On Mon 2014-02-03 11:56, Gunnar Morling wrote: > Hi, > > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements > Serializable. When is it actually serialized? > > I'm suspecting the answer is "never", as the type of the "metadata" member > is not serializable, so I'd expect a NotSerializableException to be raised. > > If so, does anything speak against making AssociationKey not implement > Serializable? > > Thanks, > > --Gunnar > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM depending on ORM 4.3
On Sat 2014-02-01 18:47, Sanne Grinovero wrote: > On 27 January 2014 10:32, Gunnar Morling wrote: > > Looking at the issues which have been addressed or are work in progress > > since the last release [1] I don't think we need a tag. > > +1 especially as I understand JPA 2.1 is backwards compatible It is not for containers and the app stack you use in general. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
On 3 February 2014 12:12, Gunnar Morling wrote: > 2014/2/3 Sanne Grinovero >> >> If you store anything in Infinispan, it should at the very least be >> Serializable. >> >> A better solution would be to provide custom Externalizers: >> https://hibernate.atlassian.net/browse/OGM-37 > > > Ah, I see. I like the Externalizer approach as I found it surprising that AK > implements Serializable as there apparently is no need for it from the > perspective of the core engine itself. >> >> >> >> On 3 February 2014 10:56, Gunnar Morling wrote: >> > Hi, >> > >> > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements >> > Serializable. When is it actually serialized? >> >> When you use Infinispan in clustered mode. >> >> > >> > I'm suspecting the answer is "never", as the type of the "metadata" >> > member >> > is not serializable, so I'd expect a NotSerializableException to be >> > raised. >> >> Our problem is probably that we don't have integration tests using >> Infinispan in modes other than "Local". >> I suspect I avoided making them as they make the testsuite slower, but >> it seems you just highlighted an important reason to add them :-/ > > > Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for adding a > test for this scenario. I'm still wondering how it supposed to work given > that AssociationKey contains a non-serializable non-transient member. That's a problem, we need to remove it. I can help making the Infinispan tests but would be nice if you could start removing the non-serializable members, or track it as a separate issue. That would help me a lat, as I fear I've got a bit out of touch with that area of OGM. >> >> > >> > If so, does anything speak against making AssociationKey not implement >> > Serializable? >> >> It's needed. Also I think it's an important "warning flag" in terms of >> design: never consider hooking references to services in such a key, >> and strive to keep it as a very simple value holder. > > > Hum, not sure whether making a type Serializable is the right way to > indicate such a matter. But of course the requirement stands as is for > Infinispan as you describe, at least unless that Externalizer-based approach > gets implemented. I guess it's a matter of habits. If I see a class declaring "Serializable" it (personally) affects my design considerations. Sanne > > Thanks for the clarification, > > --Gunnar > > >> >> >> -- Sanne >> >> > >> > Thanks, >> > >> > --Gunnar >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
On 3 February 2014 13:33, Emmanuel Bernard wrote: > Hum, with the fact that this object now points to metadata, I wonder if > we should force EhCache, Map and Infinispan to have their own version of > EntityKey / RowKey and AssociationKey (or an appropriate externalizer). Ok to consider it, but let's keep an eye on performance requirements: allocating twice the objects which are strictly necessary is probably not going to help. Maybe if these where interfaces, each GridDialect could make his own type ? Sanne > > Emmanuel > > On Mon 2014-02-03 11:56, Gunnar Morling wrote: >> Hi, >> >> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements >> Serializable. When is it actually serialized? >> >> I'm suspecting the answer is "never", as the type of the "metadata" member >> is not serializable, so I'd expect a NotSerializableException to be raised. >> >> If so, does anything speak against making AssociationKey not implement >> Serializable? >> >> Thanks, >> >> --Gunnar >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
2014/2/3 Sanne Grinovero > On 3 February 2014 12:12, Gunnar Morling wrote: > > 2014/2/3 Sanne Grinovero > >> > >> If you store anything in Infinispan, it should at the very least be > >> Serializable. > >> > >> A better solution would be to provide custom Externalizers: > >> https://hibernate.atlassian.net/browse/OGM-37 > > > > > > Ah, I see. I like the Externalizer approach as I found it surprising > that AK > > implements Serializable as there apparently is no need for it from the > > perspective of the core engine itself. > >> > >> > >> > >> On 3 February 2014 10:56, Gunnar Morling wrote: > >> > Hi, > >> > > >> > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements > >> > Serializable. When is it actually serialized? > >> > >> When you use Infinispan in clustered mode. > >> > >> > > >> > I'm suspecting the answer is "never", as the type of the "metadata" > >> > member > >> > is not serializable, so I'd expect a NotSerializableException to be > >> > raised. > >> > >> Our problem is probably that we don't have integration tests using > >> Infinispan in modes other than "Local". > >> I suspect I avoided making them as they make the testsuite slower, but > >> it seems you just highlighted an important reason to add them :-/ > > > > > > Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for > adding a > > test for this scenario. I'm still wondering how it supposed to work given > > that AssociationKey contains a non-serializable non-transient member. > > That's a problem, we need to remove it. > I can help making the Infinispan tests but would be nice if you could > start removing the non-serializable members, or track it as a separate > issue. That would help me a lat, as I fear I've got a bit out of touch > with that area of OGM. > Created https://hibernate.atlassian.net/browse/OGM-435 for it. Thanks for having an eye on that test. If you need any support with that let me know. > > >> > >> > > >> > If so, does anything speak against making AssociationKey not implement > >> > Serializable? > >> > >> It's needed. Also I think it's an important "warning flag" in terms of > >> design: never consider hooking references to services in such a key, > >> and strive to keep it as a very simple value holder. > > > > > > Hum, not sure whether making a type Serializable is the right way to > > indicate such a matter. But of course the requirement stands as is for > > Infinispan as you describe, at least unless that Externalizer-based > approach > > gets implemented. > > I guess it's a matter of habits. If I see a class declaring > "Serializable" it (personally) affects my design considerations. > Yes, sure. But the question is what's the intention of making a given type serializable; for me it was surprising that AssociationKey is used as is and passed to a datastore, so far I only perceived it as type which is used *within* OGM and its dialects which then create the right representation to persist that info (hence my original question). If AssociationKey and friends are actually designed to be used themselves in the stores, we should document that, in particular since we must take care when evolving these types. > > Sanne > > > > > Thanks for the clarification, > > > > --Gunnar > > > > > >> > >> > >> -- Sanne > >> > >> > > >> > Thanks, > >> > > >> > --Gunnar > >> > ___ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
2014/2/3 Sanne Grinovero > On 3 February 2014 13:33, Emmanuel Bernard wrote: > > Hum, with the fact that this object now points to metadata, I wonder if > > we should force EhCache, Map and Infinispan to have their own version of > > EntityKey / RowKey and AssociationKey (or an appropriate externalizer). > > Ok to consider it, but let's keep an eye on performance requirements: > allocating twice the objects which are strictly necessary is probably > not going to help. > But using a backend-specific externalizer would avoid that, right? This appears as the preferred option to me so far. > Maybe if these where interfaces, each GridDialect could make his own type ? > Maybe, but these types are instantiated by the core engine, so we'd have to enhance GridDialect with (factory) methods for creating instances. > > Sanne > > > > > Emmanuel > > > > On Mon 2014-02-03 11:56, Gunnar Morling wrote: > >> Hi, > >> > >> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements > >> Serializable. When is it actually serialized? > >> > >> I'm suspecting the answer is "never", as the type of the "metadata" > member > >> is not serializable, so I'd expect a NotSerializableException to be > raised. > >> > >> If so, does anything speak against making AssociationKey not implement > >> Serializable? > >> > >> Thanks, > >> > >> --Gunnar > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM depending on ORM 4.3
On 3 February 2014 13:34, Emmanuel Bernard wrote: > On Sat 2014-02-01 18:47, Sanne Grinovero wrote: >> On 27 January 2014 10:32, Gunnar Morling wrote: >> > Looking at the issues which have been addressed or are work in progress >> > since the last release [1] I don't think we need a tag. >> >> +1 especially as I understand JPA 2.1 is backwards compatible > > It is not for containers and the app stack you use in general. haa, right. What do you have in mind specifically? Like an JBossAS 7.1 wanting to use OGM ? I'm sure we could make modules for it, for Hibernate (native API) users, but I don't know how it would work as a JPA provider. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM depending on ORM 4.3
On Mon 2014-02-03 14:58, Sanne Grinovero wrote: > On 3 February 2014 13:34, Emmanuel Bernard wrote: > > On Sat 2014-02-01 18:47, Sanne Grinovero wrote: > >> On 27 January 2014 10:32, Gunnar Morling wrote: > >> > Looking at the issues which have been addressed or are work in progress > >> > since the last release [1] I don't think we need a tag. > >> > >> +1 especially as I understand JPA 2.1 is backwards compatible > > > > It is not for containers and the app stack you use in general. > > haa, right. > What do you have in mind specifically? Like an JBossAS 7.1 wanting to use OGM > ? > > I'm sure we could make modules for it, for Hibernate (native API) > users, but I don't know how it would work as a JPA provider. I am preparing for adoption. So any container really (Weblo, Websphere, Tomcat, TomEE, Spring x.y etc etc). ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0
Resending as I screwed up the Hibernate Dev email. On Mon 2014-02-03 14:28, Emmanuel Bernard wrote: > Hello Hardy, Sanne and all, > > I think it's time to discuss the schedule we want for Hibernate Search > 5. While we don't usually use time boxing, it's still useful to try and > shoot for a rough capped timing. > > I have proposed several options for the meeting on Doodle, make sure to > set the time zone correctly. > > http://doodle.com/8mfadig97447bb4s#table > > Anyone is welcome to join of course and we will try to accommodate for > most. But the propose schedules tend to be European friendly and if > possible I'd love to get this meeting done by Wed. > > Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] postgres dialect and wildfly
Hey, My Hibernate knowledge is really dated, but, within a Wildfly/AS7/JPA deployment don't you still have to specify the SQL dialect in your persistence.xml? Or is this automatically figured out now? I have a user that is seeing postgres org.postgresql.util.PSQLException: ERROR: operator does not exist Errors and I thought setting the dialect might yelp. Thanks. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Feature Proposal for Hibernate Search
Hi, I am currently working on a new way to query in Hibernate Search. It's not finished, but it already works. I am planning on extending the functionality a lot in the future and I thought this could be a nice addition to Hibernate Search. What do you think? https://github.com/s4ke/HibernateSearchQueryExtension Martin Braun martinbraun...@aol.com www.github.com/s4ke ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] postgres dialect and wildfly
Oops, to everyone this time :) Hibernate automatically determines the Dialect to use based on JDBC metadata *if* a Dialect is not explicitly set. In fact letting it auto detect is the recommended behavior, just setting Dialect explicitly when using a custom Dialect for some reason. There is also a way to affect the auto resolution (for integrators). On Mon, Feb 3, 2014 at 10:06 AM, Bill Burke wrote: > Hey, > > My Hibernate knowledge is really dated, but, within a Wildfly/AS7/JPA > deployment don't you still have to specify the SQL dialect in your > persistence.xml? Or is this automatically figured out now? > > I have a user that is seeing postgres org.postgresql.util.PSQLException: > ERROR: operator does not exist > > Errors and I thought setting the dialect might yelp. > > Thanks. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0
If IRC doesn't work at the selected time, let's use: https://gitter.im/hibernate/hibernate-search On 3 February 2014 15:17, Emmanuel Bernard wrote: > Resending as I screwed up the Hibernate Dev email. > > On Mon 2014-02-03 14:28, Emmanuel Bernard wrote: >> Hello Hardy, Sanne and all, >> >> I think it's time to discuss the schedule we want for Hibernate Search >> 5. While we don't usually use time boxing, it's still useful to try and >> shoot for a rough capped timing. >> >> I have proposed several options for the meeting on Doodle, make sure to >> set the time zone correctly. >> >> http://doodle.com/8mfadig97447bb4s#table >> >> Anyone is welcome to join of course and we will try to accommodate for >> most. But the propose schedules tend to be European friendly and if >> possible I'd love to get this meeting done by Wed. >> >> Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0
This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :) Ps: I thought I was to blame for freenode issues but apparently no :) > On 3 févr. 2014, at 20:01, Sanne Grinovero wrote: > > If IRC doesn't work at the selected time, let's use: > https://gitter.im/hibernate/hibernate-search > >> On 3 February 2014 15:17, Emmanuel Bernard wrote: >> Resending as I screwed up the Hibernate Dev email. >> >>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote: >>> Hello Hardy, Sanne and all, >>> >>> I think it's time to discuss the schedule we want for Hibernate Search >>> 5. While we don't usually use time boxing, it's still useful to try and >>> shoot for a rough capped timing. >>> >>> I have proposed several options for the meeting on Doodle, make sure to >>> set the time zone correctly. >>> >>> http://doodle.com/8mfadig97447bb4s#table >>> >>> Anyone is welcome to join of course and we will try to accommodate for >>> most. But the propose schedules tend to be European friendly and if >>> possible I'd love to get this meeting done by Wed. >>> >>> Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin, great that you like Hibernate Search and want to make it even easier to use. On 3 Jan 2014, at 19:08, Martin Braun wrote: > I am currently working on a new way to query in Hibernate Search. It's not > finished, but > it already works. I had a quick look at the code, but for the sake of discussion, it would be great if you could outline your approach in an email. Maybe with some example code? It would make it much easier for everyone interested to see what you want to achieve. Let me try to sum your approach up from what I read in the readme and glancing at the code. Please correct me from where I am wrong. Your approach is bean driven, where the bean defines the query parameters you have for a given query. You also created a set of annotations which allow you to specify the query via annotations on the bean. When you create a Searcher you pass it the bean and the parameter values. From there is query is build and executed for you. Is this correct? How would you provide multiple parameters and how do you select a given query in a bean (it seems you envision the possibility to provide more than one). Is this correct? > I am planning on extending the functionality a lot in the future What are your plans? Can you maybe share your vision for this extension? How would you envision to integrate it with Search? Do you need to modify core functionality or could this be an optional “search” module? —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi again,
hardy is right. Here is a longer version of the proposal (that is more
discussion friendly):
> I had a quick look at the code, but for the sake of discussion, it would be
> great if you could outline
> your approach in an email. Maybe with some example code? It would make it
> much
> easier for everyone
> interested to see what you want to achieve.
Okay. Let me explain my idea with this little example:
We have a fulltext enabled search that takes multiple parameters. For easier
usage we have a parameter-wrapper similar to this:
public class PlaceQueryBean {
private String name;
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
This is just a shortened version with only one parameter. But if we wanted to
write a Hibernate Search Query, it would look similar to this:
queryBuilder.term().onField("name").matching(queryBean.getName())...
As the parameters get more the query gets bigger and bigger and you have to
"manually" retrieve the data out of the Query-Bean (which is easier to use than
vanilla Lucene queries, but you are still required to write a lot of
boilerplate code).
In my Extension a query like that would only have to be added to the class via
annotations. You only have to write the query-structure and lose the hand
written queries. And another big plus: The query logic is in the exact same
spot where the data is (and not in the service).
@Queries(@Query(must = @Must(@SearchField(fieldName = "name", propertyName =
"name"
public class PlaceQueryBean extends BaseQueryBean {
private String name;
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
> Your approach is bean driven, where the bean defines the query parameters you
>
> have for a given query.
Yes that's correct, but I am thinking which methods of the BeanInterface can be
moved to the Annotations.
And by these "callback"-methods from the Searcher you can still build normal
Hibernate-Search queries.
> You also created a set of annotations which allow you to specify the query
> via
> annotations on the bean.
Yes.
> When you create a Searcher you pass it the bean and the parameter values.
> From
> there is query is build
> and executed for you. Is this correct?
Yes.
> How would you provide multiple parameters
What do you mean by that? Normally you would pass a Bean that has a list of
values. Which junction
to use there is specified in the SearchField Annotation via the betweenValues()
property.
> and how do you select
> a given query in a bean (it seems you envision the possibility to provide
> more
> than one).
Yes. You can pass a optional profile value to the Searcher.
> What are your plans? Can you maybe share your vision for this extension? How
> would you envision to
> integrate it with Search?
I plan on moving most of the stuff that has to be hand-written to bean
declarations (Sorts, Filters, etc.)
Do you need to modify core functionality or could this
> be an optional “search” module?
I don't think I'd need to modify any core functionality.
I hope I have done better this time :).
Martin Braun
martinbraun...@aol.com
www.github.com/s4ke
-Original Message-
From: Hardy Ferentschik
To: Martin Braun
Cc: Hibernate
Sent: Mon, Feb 3, 2014 9:13 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin,
great that you like Hibernate Search and want to make it even easier to use.
On 3 Jan 2014, at 19:08, Martin Braun wrote:
> I am currently working on a new way to query in Hibernate Search. It's not
finished, but
> it already works.
I had a quick look at the code, but for the sake of discussion, it would be
great if you could outline
your approach in an email. Maybe with some example code? It would make it much
easier for everyone
interested to see what you want to achieve.
Let me try to sum your approach up from what I read in the readme and glancing
at the code. Please
correct me from where I am wrong.
Your approach is bean driven, where the bean defines the query parameters you
have for a given query.
You also created a set of annotations which allow you to specify the query via
annotations on the bean.
When you create a Searcher you pass it the bean and the parameter values. From
there is query is build
and executed for you. Is this correct? How would you provide multiple
parameters
and how do you select
a given query in a bean (it seems you envision the possibility to provide more
than one).
Is this correct?
> I am planning on extending the functionality a lot in the future
What are your plans? Can you maybe share your vision for this extension? How
would you envision to
integrate it with Search? Do you need to modify core functionality or could
this
be an optional “search” module?
—Hardy
___
Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin, That's interesting. I have a couple of questions for you. What is the notion of profile and when would you use it? When do you need and use sub query ids? The issue you had was to map getters to query parameters in an easier way than currently possible, correct? It reminds me a little bit of the Example query with a parameter twist. I have to admit, I am a bit skeptical on a few things: - having to extend a technical class - I don't think annotations are the best way to express queries but you probably have your reasons, so let's discuss them :) Have you explored the ability to write the query programmatically while still making use of the getter binding? I can imagine we could update the DSL to accept the parameters holder and have them injected. I wonder if literally an Example API would address your use cases ? Thanks the first thoughts Emmanuel > On 3 févr. 2014, at 19:08, Martin Braun wrote: > > > Hi, > > > I am currently working on a new way to query in Hibernate Search. It's not > finished, but > it already works. I am planning on extending the functionality a lot in the > future and > I thought this could be a nice addition to Hibernate Search. What do you > think? > > > https://github.com/s4ke/HibernateSearchQueryExtension > > > Martin Braun > martinbraun...@aol.com > www.github.com/s4ke > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Feature Proposal for Hibernate Search
HI Emmanuel, Hi Martin, > That's interesting. I have a couple of questions for you. > What is the notion of profile and when would you use it? This can be used when you'd like to be able to use the same queryBean in different contexts sou you don't have to write a different Bean if you only need a query that's a little bit different. > When do you need and use sub query ids? This is needed if you want to do queries like this (explained in boolean-logic): (queryA && (!queryB || queryC)). You can get as complicated as you want with this. These SubQueries are mainly used because Java doesn't allow recursiveness in Annotations. > The issue you had was to map getters to query parameters in an easier way > than > currently possible, correct? It reminds me a little bit of the Example query > with a parameter twist. Which one are you talking about? > I have to admit, I am a bit skeptical on a few things: > - having to extend a technical class I am too, As stated in the e-mail before I want to get away from that design but I still want to be able to write queries myself if I want to. This can be done with Annotations on Method-Level or with QueryProviders in an extra Annotation on the Type-Level. > - I don't think annotations are the best way to express queries but you > probably > have your reasons, so let's discuss them :) Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data. > Have you explored the ability to write the query programmatically while still > making use of the getter binding? I can imagine we could update the DSL to > accept the parameters holder and have them injected. I think that would be possible, but then you would still have to handle the query nesting and such by hand and that code would be more complicated to use (but easier to debug, tbh). > I wonder if literally an Example API would address your use cases ? What do you mean by that? Martin Braun martinbraun...@aol.com www.github.com/s4ke -Original Message- From: Emmanuel Bernard To: Martin Braun Cc: hibernate-dev Sent: Mon, Feb 3, 2014 9:45 pm Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search Hi Martin, That's interesting. I have a couple of questions for you. What is the notion of profile and when would you use it? When do you need and use sub query ids? The issue you had was to map getters to query parameters in an easier way than currently possible, correct? It reminds me a little bit of the Example query with a parameter twist. I have to admit, I am a bit skeptical on a few things: - having to extend a technical class - I don't think annotations are the best way to express queries but you probably have your reasons, so let's discuss them :) Have you explored the ability to write the query programmatically while still making use of the getter binding? I can imagine we could update the DSL to accept the parameters holder and have them injected. I wonder if literally an Example API would address your use cases ? Thanks the first thoughts Emmanuel > On 3 févr. 2014, at 19:08, Martin Braun wrote: > > > Hi, > > > I am currently working on a new way to query in Hibernate Search. It's not finished, but > it already works. I am planning on extending the functionality a lot in the future and > I thought this could be a nice addition to Hibernate Search. What do you think? > > > https://github.com/s4ke/HibernateSearchQueryExtension > > > Martin Braun > martinbraun...@aol.com > www.github.com/s4ke > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] When is AssociationKey serialized?
> On 3 févr. 2014, at 15:21, Sanne Grinovero wrote: > >> On 3 February 2014 13:33, Emmanuel Bernard wrote: >> Hum, with the fact that this object now points to metadata, I wonder if >> we should force EhCache, Map and Infinispan to have their own version of >> EntityKey / RowKey and AssociationKey (or an appropriate externalizer). > > Ok to consider it, but let's keep an eye on performance requirements: > allocating twice the objects which are strictly necessary is probably > not going to help. > Maybe if these where interfaces, each GridDialect could make his own type ? > The thing is only the key/value dialects do make use of the keys objects. And even in that case, it might not make sense to actually reuse these objects. For example if the cache name is the table and only the id columns are part of the key. Is that edge case worth this complexity (interfaces and splitting the metadata)? Maybe with optional methods in the grid dialect? That would still make me sad I guess :) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Feature Proposal for Hibernate Search
The example API I was thinking about is http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#querycriteria-examples > On 3 févr. 2014, at 21:57, Martin Braun wrote: > > HI Emmanuel, > Hi Martin, > > > That's interesting. I have a couple of questions for you. > > What is the notion of profile and when would you use it? > This can be used when you'd like to be able to use the same queryBean in > different contexts > sou you don't have to write a different Bean if you only need a query that's > a little bit different. > > When do you need and use sub query ids? > This is needed if you want to do queries like this (explained in > boolean-logic): > (queryA && (!queryB || queryC)). > You can get as complicated as you want with this. These SubQueries are mainly > used because > Java doesn't allow recursiveness in Annotations. > > The issue you had was to map getters to query parameters in an easier way > > than > > currently possible, correct? It reminds me a little bit of the Example > > query > > with a parameter twist. > Which one are you talking about? > > I have to admit, I am a bit skeptical on a few things: > > - having to extend a technical class > I am too, As stated in the e-mail before I want to get away from that design > but I still > want to be able to write queries myself if I want to. This can be done with > Annotations on > Method-Level or with QueryProviders in an extra Annotation on the Type-Level. > > - I don't think annotations are the best way to express queries but you > > probably > > have your reasons, so let's discuss them :) > Why? I think it's not hard to read an you have the query right with your > ParameterWrapper-class which holds your data. > > Have you explored the ability to write the query programmatically while > > still > > making use of the getter binding? I can imagine we could update the DSL to > > accept the parameters holder and have them injected. > I think that would be possible, but then you would still have to handle the > query nesting and such by hand and that code would be more complicated to use > (but easier to debug, tbh). > > I wonder if literally an Example API would address your use cases ? > What do you mean by that? > Martin Braun > martinbraun...@aol.com > www.github.com/s4ke > > > -Original Message- > From: Emmanuel Bernard > To: Martin Braun > Cc: hibernate-dev > Sent: Mon, Feb 3, 2014 9:45 pm > Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search > > Hi Martin, > > That's interesting. I have a couple of questions for you. > > What is the notion of profile and when would you use it? > > When do you need and use sub query ids? > > The issue you had was to map getters to query parameters in an easier way > than > currently possible, correct? It reminds me a little bit of the Example query > with a parameter twist. > > I have to admit, I am a bit skeptical on a few things: > - having to extend a technical class > - I don't think annotations are the best way to express queries but you > probably > have your reasons, so let's discuss them :) > > Have you explored the ability to write the query programmatically while still > making use of the getter binding? I can imagine we could update the DSL to > accept the parameters holder and have them injected. > > I wonder if literally an Example API would address your use cases ? > > Thanks the first thoughts > > Emmanuel > > > On 3 févr. 2014, at 19:08, Martin Braun wrote: > > > > > > Hi, > > > > > > I am currently working on a new way to query in Hibernate Search. It's not > finished, but > > it already works. I am planning on extending the functionality a lot in the > future and > > I thought this could be a nice addition to Hibernate Search. What do you > think? > > > > > > https://github.com/s4ke/HibernateSearchQueryExtension > > > > > > Martin Braun > > martinbraun...@aol.com > > www.github.com/s4ke > > > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Feature Proposal for Hibernate Search
> On 3 févr. 2014, at 21:57, Martin Braun wrote: > > I have to admit, I am a bit skeptical on a few things: > > - having to extend a technical class > I am too, As stated in the e-mail before I want to get away from that design > but I still > want to be able to write queries myself if I want to. This can be done with > Annotations on > Method-Level or with QueryProviders in an extra Annotation on the Type-Level. You lost me :) Could you write some code, maybe in a gist.github.com ? > > - I don't think annotations are the best way to express queries but you > > probably > > have your reasons, so let's discuss them :) > Why? I think it's not hard to read an you have the query right with your > ParameterWrapper-class which holds your data. Indeed I like that both the query and the parameter values are hosted on the same class. And I would have the programmatic query expressed on that class. (I know it goes against my later proposal to provide params support in the DSL itself but I explore multiple routes :) ). This also solves another problem we have today of propagating the entity type to the creation of the full text query. But annotations in my opinion don't scale very well for tree structures. Composition, lack of polymorphism are also not easy / elegant in annotations. You can see that you had to break the sub queries with string references. And I am not sure how you will be able to express other query types that we have like range, spatial etc. I might be wrong, so it's worth trying. But even then, if we had one new query type, we have to also add an equivalent annotation or add new fields to an existing one. > > Have you explored the ability to write the query programmatically while > > still > > making use of the getter binding? I can imagine we could update the DSL to > > accept the parameters holder and have them injected. > I think that would be possible, but then you would still have to handle the > query nesting and such by hand and that code would be more complicated to use > (but easier to debug, tbh). What do you mean by query nesting by hand? And how does the annotation approach differs? > > I wonder if literally an Example API would address your use cases ? > What do you mean by that? > Martin Braun > martinbraun...@aol.com > www.github.com/s4ke > > > -Original Message- > From: Emmanuel Bernard > To: Martin Braun > Cc: hibernate-dev > Sent: Mon, Feb 3, 2014 9:45 pm > Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search > > Hi Martin, > > That's interesting. I have a couple of questions for you. > > What is the notion of profile and when would you use it? > > When do you need and use sub query ids? > > The issue you had was to map getters to query parameters in an easier way > than > currently possible, correct? It reminds me a little bit of the Example query > with a parameter twist. > > I have to admit, I am a bit skeptical on a few things: > - having to extend a technical class > - I don't think annotations are the best way to express queries but you > probably > have your reasons, so let's discuss them :) > > Have you explored the ability to write the query programmatically while still > making use of the getter binding? I can imagine we could update the DSL to > accept the parameters holder and have them injected. > > I wonder if literally an Example API would address your use cases ? > > Thanks the first thoughts > > Emmanuel > > > On 3 févr. 2014, at 19:08, Martin Braun wrote: > > > > > > Hi, > > > > > > I am currently working on a new way to query in Hibernate Search. It's not > finished, but > > it already works. I am planning on extending the functionality a lot in the > future and > > I thought this could be a nice addition to Hibernate Search. What do you > think? > > > > > > https://github.com/s4ke/HibernateSearchQueryExtension > > > > > > Martin Braun > > martinbraun...@aol.com > > www.github.com/s4ke > > > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [ORM] Depending on jboss-logging-annotations ?
I see I'm now having a dependency pulled in by maven to: org.jboss.logging:jboss-logging-annotations This is being included as a transitive dependency via each of: - org.hibernate:hibernate-core:jar:4.3.1.Final - org.hibernate:hibernate-testing:jar:4.3.1.Final - org.hibernate:hibernate-entitymanager:jar:4.3.1.Final - org.hibernate.common:hibernate-commons-annotations:jar:4.0.4.Final I assume this is a simple mistake in the build settings? Or do we actually need this at runtime? Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0
Turns out it conflicts with the other Hibernate general meeting on IRC. So we are moving it up 30 mins from 16:00 to 17:00 CET. > On 3 févr. 2014, at 20:58, Emmanuel Bernard wrote: > > This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :) > > Ps: I thought I was to blame for freenode issues but apparently no :) > >> On 3 févr. 2014, at 20:01, Sanne Grinovero wrote: >> >> If IRC doesn't work at the selected time, let's use: >> https://gitter.im/hibernate/hibernate-search >> >>> On 3 February 2014 15:17, Emmanuel Bernard wrote: >>> Resending as I screwed up the Hibernate Dev email. >>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote: Hello Hardy, Sanne and all, I think it's time to discuss the schedule we want for Hibernate Search 5. While we don't usually use time boxing, it's still useful to try and shoot for a rough capped timing. I have proposed several options for the meeting on Doodle, make sure to set the time zone correctly. http://doodle.com/8mfadig97447bb4s#table Anyone is welcome to join of course and we will try to accommodate for most. But the propose schedules tend to be European friendly and if possible I'd love to get this meeting done by Wed. Emmanuel > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
