From giriraj.sharma27 at gmail.com Mon Mar 3 08:32:19 2014 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Mon, 3 Mar 2014 19:02:19 +0530 Subject: [hibernate-dev] GSoc : Sample project ideas on "JBoss AS Quickstarts: Hibernate" mentioned in JBoss GSoc 2014 ideas Page. Message-ID: Hii,I am Giriraj Sharma (http://girirajsharma27.wix.com/giriraj), a dedicated GSoc aspirant(3 years experience in JavaSE+1.5 years experience in JavaEE) from Dept. of Computer Science, National Institute of Technology,HP,India, interested in making valuable contribution to the project JBoss AS Quickstarts: Hibernate proposed in GSoc14 ideas Page ( https://community.jboss.org/wiki/GSOC14Ideas?_sscc=t). ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- GSoc Project Proposal Ideas Page: *https://community.jboss.org/wiki/GSOC14Ideas * JBoss AS Quickstarts: Hibernate *Status:* Proposed *Summary of idea: JBoss offers a collection of quickstarts - simple applications which demonstrate a single use case or feature of JBoss AS 7. A full list can be viewed at https://docs.jboss.org/author/display/AS71/Contributing+a+Quickstart . This project involves building out three new quickstarts to show off Hibernate Search, and multitennancy for Hibernate ORM. Additionally the project should research and develop two further use cases for the Hibernate group of projects that show off common uses of Hibernate in JBoss AS 7.* *You should have a strong interest in building examples, and showing people how to use technology. Domain expertise can be provided if needed.* *Knowledge prerequisite: Java* *Skill level:* *Contact(s): Pete Muir * *Mentor(s): Pete Muir, Sande Gilda, Burr Sutter* *Associated project(s): Trailblazer SIG * --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I have already forked *jboss-developer/jboss-eap-quickstarts* repository from github and I have read the guide to contributing to a quickstart ( http://www.jboss.org/jdf/quickstarts/get-involved/).* I have been actively committing on git repository *( https://github.com/jboss-developer/jboss-eap-quickstarts)* since past 15-20 days.One of my commit has been merged and my several other(11) commits are under code review.*Since past 2-3 weeks,I had been reading through official documentation of hibernate orm and I found it really very enthusiastic and interesting project to work upon this summer.I have formulated a few quickstart ideas from beginnerto advance and *wishing for a review so that I may improve it further and add up something in case I may be missing it out.* I have mentioned MySQl as a db instance,but,I may choose between MySQL,PostgreSQL, NoSQL or in-memory databases(H2,HSQLDB) or any other DB depending upon which suits the best for a particular quickstart.* Sorry,for poor formatting of tables as Gmail body content doesnt likes bullets and numbering.I am attaching a word file as well with properly and nicely formatted quickstart tables document*. Suggestions and Improvements are most welcome.I would be pleased to elaborate upon any of the quickstarts mentioned below.Thanks in advance :) *Quick start Name* *Technologies* *Demonstration* *Description* *Experience* *Tags : Hibernate Hello World, Hibernate Integration* ? *Hibernate Hello World using Annotation* Hibernate, Maven, MySQL CRUD application in Hibernate using Java 5 Annotation Beginner ? *Hibernate Hello World using XML Mapping* Hibernate, Maven, MySQL CRUD application in Hibernate using Java XML Mapping Beginner ? *Hibernate + Spring 3 MVC Hello World* Hibernate, Spring 3, Maven, MySQL, JSP/JSF Integration of Hibernate with Spring3 framework. Simple Contact Manager app which will allow user to add new contacts. The list of contacts will be displayed and user will be able to delete existing contacts. Beginner ? *Hibernate + Struts2 MVC Hello World* Hibernate, Strust2, Maven, MySQL, JSP/JSF Integration of Hibernate with Struts2 framework. Simple Contact Manager app which will allow user to add new contacts. The list of contacts will be displayed and user will be able to delete existing contacts. Beginner ? *Hibernate + Struts2 + Spring3 MVC Hello World* Hibernate, Strust2, Spring3, Maven, MySQL, JSP/JSF Integration of Hibernate with Struts2 and Spring3 framework. Simple customer management (add and select) web application. Beginner ? *Saving/Retrieving BLOB object in Spring 3 MVC and Hibernate* Hibernate, Spring 3, Maven, MySQL, JSP/JSF Spring 3 MVC and Hibernate demo to store and retrieve blob objects from database. Document manager application which will allow user to upload, download and delete a document or file. Intermediate ? *Writing a URL Shorten app in Java Struts2 & Hibernate* Hibernate,Struts2 ,MySQL, JSP/JSF Simple URL shorten service in pure JEE with Struts2 and Hibernate. A web application which will allow user with URL shorten service and see statistics/details of any short URL. Intermediate *Quick start Name* *Technologies* *Demonstration* *Description* *Experience* *Tags : Hibernate Association (Table Relationship),Hibernate Mapping* ? *Table Per Concrete Class (Annotation & XML mapping)* ? *Hibernate Inheritance: Table Per Subclass (Annotation & XML mapping)* ? *Hibernate Inheritance: Table Per Class Hierarchy (Annotation & XML Mapping)* Hibernate, Maven, MySQL Hibernate Inheritance CRUD application showing Hibernate Inheritance: One Table per Concrete Class/Subclass/Class Hierarchy scheme. Beginner ? *Hibernate One To One Mapping* *(XML, Annotation)* Hibernate, Maven, MySQL Hibernate Mapping. One-to-one mapping in Hibernate framework using XML/Annotation Mapping. Beginner ? *Hibernate One To Many Mapping* *(XML, Annotation)* Hibernate, Maven, MySQL Hibernate Mapping. One-to-many mapping in Hibernate framework using XML/Annotation Mapping. Beginner ? *Hibernate Many To Many Mapping* *(XML, Annotation)* Hibernate, Maven, MySQL Hibernate Mapping. Many-to-many mapping in Hibernate framework using XML/Annotation Mapping. Beginner ? *Hibernate Self Join One To Many Annotations Mapping * Hibernate, Maven, MySQL Hibernate self-join Mapping. Self-Reference one to many relationship using Annotation mapping. Beginner ? *Hibernate Self Join Many To Many Annotations Mapping* Hibernate, Maven, MySQL Hibernate self-join Mapping. Self-Reference many to many relationship using Annotation mapping. Beginner *Quick start Name* *Technologies* *Demonstration* *Description* *Experience* *Tags : Hibernate Query Language, Hibernate Criteria API* ? *Hibernate Query Language* ? *Hibernate parameter binding* ? *Hibernate Native SQL* ? *Hibernate Named Query* Hibernate, Maven, MySQL HQL, Parameter binding, Native SQL, Named query CRUD application using HQL, parameter binding with "Named parameters" and "Positional parameters" methods, Native SQL and named query. Beginner ? *Hibernate Criteria API* Hibernate, Maven, MySQL Hibernate Criteria API. CRUD application using basic query, ordering query, restrictions query and paging the result. Beginner ? *Hibernate Transaction* Hibernate, Maven, MySQL Hibernate Transaction API A simple standard example to show Hibernate transaction. Beginner *Quick start Name* *Technologies* *Demonstration* *Description* *Experience* *Tags : Hibernate Validator, Search, OGM, Multi-tenancy, Shards* ? *Hibernate Validator* Unified Expression Language (EL), CDI, Hibernate Bean Validation API Bean Validation using built in and custom user defined constraints. Intermediate ? *Hibernate Search* Hibernate Search, Hibernate ORM, JPA 2.1, JSP/JSF ? Apache Lucene API ? Analyzer configuration (Default analyzer and analyzer by class) and field bridges (Bridges) ? Clustering (JMS Master/Slave back end, Infinispan Directory configuration) ? Large index handling (Sharding Indexes) ? Spatial Indexing ? Faceting and geolocation Demo web application showing ? Enabled full-text search capabilities on your Entities. ? Indexing ? Searching ? Order results by relevance ? Find by approximation (fuzzy search) Advanced ? *Hibernate OGM -JPA for NoSQL* Hibernate OGM, Maven, JPA 2.0, Mongo DB or Infinispan or Ehcache as integration for targeting multiple data stores. ? Java & Mongo Object Data Mapping with Hibernate OGM ? Java Persistence API (JPA) support to the NoSQL ? Hibernate Search along with Apache Lucene ? Leveraging standard JPA semantics to operate with key/value and NoSQL Simple regular EntityManager using Mongo Object Data Mapping with Hibernate OGM for creating, deleting and finding entities by ID, and using a FullTextEntityManager instance to perform searching. Advanced ? *Hibernate Multi tenancy* Hibernate ORM, Spring3, Maven, MySQL/PostgreSQL, JSP/JSF 1.Multi-tenant data approaches ? Separate database ? Separate schema ? Partitioned (Discriminator data) 2.Strategies for CurrentTenantIdentifierResolver and MultiTenantConnectionProvider implementors using ?Single Connection Pool ? Different Connection Pools 3. Multi-tenancy support for Hibernate second level cache 4. Versioning with Hibernate envers 5. Using Hibernate to Implement Multi-tenant Cloud Architecture 1.Simple multi-tenant CRUD application exploiting multi-tenant data approaches (Separate database, Separate schema, Partitioned data) 2.Multi-tenant cloud applications with Spring-Data-JPA and Hibernate Advanced ? *Hibernate Shards* Amazon RDS, Hibernate ORM, MySQL, XML Scaling Amazon Relational Database Service using virtual shards hibernate mapping. Simple application which will shard news articles with Amazon RDS and Hibernate Shards. The news application will store and retrieve news articles across a range of topics. Sharding of articles will be on the basis of their category. Advanced -- Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur,India http://girirajsharma27.wix.com/giriraj From guillaume.smet at hibernate.org Mon Mar 3 11:11:32 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Mon, 3 Mar 2014 17:11:32 +0100 Subject: [hibernate-dev] Search: changing the way we search Message-ID: Hi, So, it's been a long time since I threw the first idea of this (see HSEARCH-917) but, after a lot more thoughts, and the fact that I'm basically stuck for a long time on this one, it's probably better to agree with a plan before putting together some code. Note that this plan is based on our usage of Hibernate Search on a lot of applications for several years and I think our usage pattern is quite common. But, even so, I'm pretty sure there are other search patterns out there which might be interesting and it would be nice to include them in this proposal if they don't fit. I. How do we search at my company? ------------------------------------------------------- We mainly use Search for 2 things: - autocompletion; - search engines: search form to filter a list of items. Usually, a plain text field and several structured fields (drop down choice mostly). We usually sort with business rules, not using score. Users usually like it better as it's more predictable. For example, we sort our autocompletion results alphabetically. An interesting note here is probably that we work on structured data, not on CMS content. This might be considered a detail but you'll see it's important. We use analyzers to: - split the words (the WordDelimiterFilter - yeah, I have a Solr background :)); - filter the input (AsciiFoldingFilter, LowercaseFilter...); - eventually do simple stemming (with our own very minimal stemmers). We sometimes use Search to find the elements to apply business rules when it's really hard to use the database to do so. Search provides a convenient way to denormalize the data. II. On why we can't use the DSL out of the box -------------------------------------------------------------------- The Hibernate Search DSL is great and I must admit this is the DSL which learned me how to build DSL for our own usage. It's intuitive, well thought, definitely a nice piece of code. So, why don't we use it for our plain text queries? (Disclaimer: we use it under the hood, we just have to do a lot of things manually outside of the DSL) Several reasons: 1/ the aforementioned detail about sorting: we need AND badly in plain text search; 2/ we often need to add a clause only if the text isn't empty or the object not null and we then need to add more logic than the fluent approach allows it (I don't have any ideas/proposals for this one but I think it's worth mentioning). And why is it not ideal: 3/ wildcard and analyzers are really a pain with Lucene and you need to implement your own cleaning stuff to get a working wildcard query. 1/ is definitely our biggest problem. III. So let's add an AND option... ----------------------------------------------- Yeah, well, that's not so easy. Let's take a look at the code, especially our dear friend ConnectedMultiFieldsTermQueryBuilder . When I started to look at HSEARCH-917, I thought it would be quite easy to build lucene queries using a Lucene QueryParser instead of all the machinery in ConnectedMultiFieldsTermQueryBuilder. It's not. Here are pointers to the main problems I have: 1/ the getAllTermsFromText is cute when you want to OR the terms but really bad when you need AND, especially when you use analyzers which returns several tokens for a term (this is the case when you use the SynonymFilter or the WordDelimiterFilter); 2/ the fieldBridge thing is quite painful for plain text search as we are not sure that all the fields have the same fieldBridge and, thus, the search terms might be different for each fields after applying the fieldBridge. These problems are not so easy to solve in an absolute kind of way. That's why I haven't made any progress on this problem. Let's illustrate the problem: - you search for "several words in my content" (without ", it's not a phrase query, just terms) - you search in the fields title, summary and content so you expect to find at least one occurrence of each term in one of these fields; - for some reason, you have a different fieldBridge on one of the fields and it's quite hard to define "at least one occurrence of each term in one of these fields" as the fieldBridge might transform the text. My point is that I don't see a way to fix the current DSL without breaking some cases (note that the current code only works because only the OR operator is supported) even if we might consider they are weird. >From my perspective, a plainText branch of the DSL could ignore the fieldBridge machinery but I'm not sure it's a good idea. That's why I would like some feedback about this before moving in this direction. I took a look at the new features of Lucene 4.7 and the new SimpleQueryParser looks kinda interesting as it's really simple and could be a good starting point to come up with a QueryParser which simply does the job for our plain text search queries. IV. About wildcard queries -------------------------------------- Let's say it frankly: wildcard queries are a pain in Lucene. Let's take an example: - You index "Parking" and you have a LowerCaseFilter so your index contains "parking"; - You search for Parking without wildcard, it will work; - You search for Parki* with wildcard, yeah, it won't work. This is due to the fact that for wildcards, the analyzers are ignored. Usually, because if you use ? or *, they can be replaced by the filters you use in your analyzers. While we all understand the Lucene point of view from a technical perspective, I don't think we can keep this position for Hibernate Search as a user friendly search framework on top of Hibernate. At Open Wide, we have a quite complex method which rewrites a search as a working autocompletion search which might work most of the time (with a high value of most...). It's kinda ugly, far from perfect and I'm wondering if we could have something more clever in Search. I once talked with Emmanuel about having different analyzers for Indexing, Querying (this is the Solr way) and Wildcards/Fuzzy search (this is IMHO a good idea as the way you want to normalize your wildcard query highly depends on the analyzer used to index your data). V. The "don't add this clause if null/empty" problem ---------------------------------------------------------------------------- Ideas welcome! VI. Provide not so bad default analyzers --------------------------------------------------------- I think it would be nice to provide default analyzers for plain text. Not necessarily ones including complex/debatable things like stemmers, but at least something which gives a good taste of Search before going into more details. Why would it be interesting? As a French speaking person, I see so much search engines out there which don't normalize accented characters, it would be nice to have something working by default. VII. Conclusion ---------------------- I would really like to make some quick progress on III. I'm pretty sure, we're not the only ones having a lot of MultiFieldQueryParser instantiations in our Search code to deal with this. And I don't talk about the numerous times when one of our developers used the DSL without even thinking it would use the OR operator. Comments welcome. -- Guillaume From brmeyer at redhat.com Mon Mar 3 11:20:30 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 3 Mar 2014 11:20:30 -0500 (EST) Subject: [hibernate-dev] Hibernate ORM 4.3.4.Final & 4.2.10.Final release -- correction to critical regression In-Reply-To: <202654220.19763601.1393863549331.JavaMail.zimbra@redhat.com> Message-ID: <246300351.19764508.1393863630557.JavaMail.zimbra@redhat.com> Shortly after releasing ORM 4.3.2.Final and 4.2.9.Final, a critical regression was found, caused by HHH-8961 and reverted/corrected by HHH-9010. Instead of creating service-pack builds, we decided to simply release the next versions. What happened to 4.3.3? Technically and unfortunately, 4.3.2 == 4.3.3 in Nexus and Central (directly my fault -- long story). TL;DR: Avoid 4.2.9.Final, 4.3.2.Final, and 4.3.3.Final. Instead, upgrade to 4.2.10.Final or 4.3.4.Final. Apologies for the confusion this has already caused! http://in.relation.to/Bloggers/HibernateORM434Final4210FinalReleased Brett Meyer Red Hat, Hibernate ORM From sanne at hibernate.org Mon Mar 3 13:01:19 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 3 Mar 2014 18:01:19 +0000 Subject: [hibernate-dev] Search: changing the way we search In-Reply-To: References: Message-ID: Hi Guillaume, that's a very welcome email, and very timely set of proposals. I'll top-post rather than try to comment inline as it's huge :) Copying your headers for convenience: I. How do we search at my company? Very useful to know how you use it. I would expect most users to focus on the full-text capabilities, still I understand your position as in a previous project we used it for full-text but not only: it was primarily used to "boost" performance of some strictly relational queries, and in such cases we where going to quite some extremes to encode necessary tokens into the index to get it to behave in a structured manner. So, that makes at least two power users using it this way, not least in the Hibernate OGM and Infinispan use cases "full text" is a nice to have but we expect the users to be primarily interested in a SQL replacement. So I think we'll have to concede that focusin on full-text only is no longer the only goal. It quite strikes me that you mention auto-completion: it has been an open JIRA but we never found a volunteer. Do you build it on top of existing infrastructure? I didn't look at it yet, but if all it takes is an example, I'd love to add it to our documentation. II. On why we can't use the DSL out of the box 1/ Not sure how to address is; if you have patches I'll be glad to include them. 2/ Good point, also reminds me previous projects: lots of boilerplate code to handle this. III. So let's add an AND option... You seem to suggest having a solution, although the cost would be breaking current API. Since we're preparing for a new major release it would be possible to consider this now. Don't wait too long ;-) TBH I haven't fully understood what you are suggesting, it would be great if we could start from a failing test to illustrate what you mean in practice? IV. About wildcard queries Great point. AFAIK we had a solution for this (yes we needed the same), which essentially required the full field to be indexed as a single token, but we'd still lowercase it, remove accents, etc. I'm not sure that's a good solution for people not understanding the implications though :) Let's start by immediately making sure we support index time vs query time analyzer choices, that's something that has been bothering me for longer. Would you create a JIRA for this? V. The "don't add this clause if null/empty" problem I like the idea, but let's split the conversation in sub-tasks. Create a JIRA too? Feel free to optimistically mark it for 5.0, but unless you can help driving this everything which can be added incrementally (like not breaking the API) we will likely move this to some 5.x, so to not prevent us to deliver a quick 5.0 (by as quick as it can be). Still I prefer at least partially discussing this kind of tasks quickly, to make sure we won't actually need to break the API soon after. VI. Provide not so bad default analyzers Ok, another great one which should be done before 5.0. Would you propose a default one? And track it on JIRA for 5.0 too. Thanks! Sanne On 3 March 2014 16:11, Guillaume Smet wrote: > Hi, > > So, it's been a long time since I threw the first idea of this (see > HSEARCH-917) but, after a lot more thoughts, and the fact that I'm > basically stuck for a long time on this one, it's probably better to > agree with a plan before putting together some code. > > Note that this plan is based on our usage of Hibernate Search on a lot > of applications for several years and I think our usage pattern is > quite common. But, even so, I'm pretty sure there are other search > patterns out there which might be interesting and it would be nice to > include them in this proposal if they don't fit. > > I. How do we search at my company? > ------------------------------------------------------- > > We mainly use Search for 2 things: > - autocompletion; > - search engines: search form to filter a list of items. Usually, a > plain text field and several structured fields (drop down choice > mostly). > > We usually sort with business rules, not using score. Users usually > like it better as it's more predictable. For example, we sort our > autocompletion results alphabetically. An interesting note here is > probably that we work on structured data, not on CMS content. This > might be considered a detail but you'll see it's important. > > We use analyzers to: > - split the words (the WordDelimiterFilter - yeah, I have a Solr background :)); > - filter the input (AsciiFoldingFilter, LowercaseFilter...); > - eventually do simple stemming (with our own very minimal stemmers). > > We sometimes use Search to find the elements to apply business rules > when it's really hard to use the database to do so. Search provides a > convenient way to denormalize the data. > > II. On why we can't use the DSL out of the box > -------------------------------------------------------------------- > > The Hibernate Search DSL is great and I must admit this is the DSL > which learned me how to build DSL for our own usage. It's intuitive, > well thought, definitely a nice piece of code. > > So, why don't we use it for our plain text queries? (Disclaimer: we > use it under the hood, we just have to do a lot of things manually > outside of the DSL) > > Several reasons: > 1/ the aforementioned detail about sorting: we need AND badly in plain > text search; > 2/ we often need to add a clause only if the text isn't empty or the > object not null and we then need to add more logic than the fluent > approach allows it (I don't have any ideas/proposals for this one but > I think it's worth mentioning). > > And why is it not ideal: > 3/ wildcard and analyzers are really a pain with Lucene and you need > to implement your own cleaning stuff to get a working wildcard query. > > 1/ is definitely our biggest problem. > > III. So let's add an AND option... > ----------------------------------------------- > > Yeah, well, that's not so easy. > > Let's take a look at the code, especially our dear friend > ConnectedMultiFieldsTermQueryBuilder . > > When I started to look at HSEARCH-917, I thought it would be quite > easy to build lucene queries using a Lucene QueryParser instead of all > the machinery in ConnectedMultiFieldsTermQueryBuilder. It's not. > > Here are pointers to the main problems I have: > 1/ the getAllTermsFromText is cute when you want to OR the terms but > really bad when you need AND, especially when you use analyzers which > returns several tokens for a term (this is the case when you use the > SynonymFilter or the WordDelimiterFilter); > 2/ the fieldBridge thing is quite painful for plain text search as we > are not sure that all the fields have the same fieldBridge and, thus, > the search terms might be different for each fields after applying the > fieldBridge. > > These problems are not so easy to solve in an absolute kind of way. > That's why I haven't made any progress on this problem. > > Let's illustrate the problem: > - you search for "several words in my content" (without ", it's not a > phrase query, just terms) > - you search in the fields title, summary and content so you expect to > find at least one occurrence of each term in one of these fields; > - for some reason, you have a different fieldBridge on one of the > fields and it's quite hard to define "at least one occurrence of each > term in one of these fields" as the fieldBridge might transform the > text. > > My point is that I don't see a way to fix the current DSL without > breaking some cases (note that the current code only works because > only the OR operator is supported) even if we might consider they are > weird. > > >From my perspective, a plainText branch of the DSL could ignore the > fieldBridge machinery but I'm not sure it's a good idea. That's why I > would like some feedback about this before moving in this direction. > > I took a look at the new features of Lucene 4.7 and the new > SimpleQueryParser looks kinda interesting as it's really simple and > could be a good starting point to come up with a QueryParser which > simply does the job for our plain text search queries. > > IV. About wildcard queries > -------------------------------------- > > Let's say it frankly: wildcard queries are a pain in Lucene. > > Let's take an example: > - You index "Parking" and you have a LowerCaseFilter so your index > contains "parking"; > - You search for Parking without wildcard, it will work; > - You search for Parki* with wildcard, yeah, it won't work. > > This is due to the fact that for wildcards, the analyzers are ignored. > Usually, because if you use ? or *, they can be replaced by the > filters you use in your analyzers. > > While we all understand the Lucene point of view from a technical > perspective, I don't think we can keep this position for Hibernate > Search as a user friendly search framework on top of Hibernate. > > At Open Wide, we have a quite complex method which rewrites a search > as a working autocompletion search which might work most of the time > (with a high value of most...). It's kinda ugly, far from perfect and > I'm wondering if we could have something more clever in Search. I once > talked with Emmanuel about having different analyzers for Indexing, > Querying (this is the Solr way) and Wildcards/Fuzzy search (this is > IMHO a good idea as the way you want to normalize your wildcard query > highly depends on the analyzer used to index your data). > > V. The "don't add this clause if null/empty" problem > ---------------------------------------------------------------------------- > > Ideas welcome! > > VI. Provide not so bad default analyzers > --------------------------------------------------------- > > I think it would be nice to provide default analyzers for plain text. > Not necessarily ones including complex/debatable things like stemmers, > but at least something which gives a good taste of Search before going > into more details. > > Why would it be interesting? As a French speaking person, I see so > much search engines out there which don't normalize accented > characters, it would be nice to have something working by default. > > VII. Conclusion > ---------------------- > > I would really like to make some quick progress on III. I'm pretty > sure, we're not the only ones having a lot of MultiFieldQueryParser > instantiations in our Search code to deal with this. And I don't talk > about the numerous times when one of our developers used the DSL > without even thinking it would use the OR operator. > > Comments welcome. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Mon Mar 3 15:13:00 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 3 Mar 2014 21:13:00 +0100 Subject: [hibernate-dev] Don't wait, upgrade - Hibernate Validator 5.1.0.Final is out! Message-ID: <203C0AEC-6131-4918-A409-907B69F8A7D1@hibernate.org> More information about Hibernate Validator 5.1.0.Final on in.relation.to - http://in.relation.to/24979.lace Enjoy! From emmanuel at hibernate.org Tue Mar 4 05:09:23 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 11:09:23 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: Message-ID: Thanks fo that very valuable input. Let me through some ideas. This email is about the AND problem. On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > > 1/ the aforementioned detail about sorting: we need AND badly in plain > text search; > > > III. So let's add an AND option... > ----------------------------------------------- > > Yeah, well, that's not so easy. > > Let's take a look at the code, especially our dear friend > ConnectedMultiFieldsTermQueryBuilder . > > When I started to look at HSEARCH-917, I thought it would be quite > easy to build lucene queries using a Lucene QueryParser instead of all > the machinery in ConnectedMultiFieldsTermQueryBuilder. It's not. > > Here are pointers to the main problems I have: > 1/ the getAllTermsFromText is cute when you want to OR the terms but > really bad when you need AND, especially when you use analyzers which > returns several tokens for a term (this is the case when you use the > SynonymFilter or the WordDelimiterFilter); Why do you say ?especially?? Isn?t it ?only" > 2/ the fieldBridge thing is quite painful for plain text search as we > are not sure that all the fields have the same fieldBridge and, thus, > the search terms might be different for each fields after applying the > fieldBridge. That would lead to different term queries but on different fields. So I am not sure I follow the problem you are describing. Any chance you can rephrase it? > > These problems are not so easy to solve in an absolute kind of way. > That's why I haven't made any progress on this problem. > > Let's illustrate the problem: > - you search for "several words in my content" (without ", it's not a > phrase query, just terms) > - you search in the fields title, summary and content so you expect to > find at least one occurrence of each term in one of these fields; If I understand you, you wan to find several and words and in and my and content in title or in summary or in content but all terms should be present in one of the field. Is that correct? What?s the use case behind? Or is that you want to find several and words and in and my and content but across all of the fields mentioned? > - for some reason, you have a different fieldBridge on one of the > fields and it's quite hard to define "at least one occurrence of each > term in one of these fields" as the fieldBridge might transform the > text. > > My point is that I don't see a way to fix the current DSL without > breaking some cases (note that the current code only works because > only the OR operator is supported) even if we might consider they are > weird. > >> From my perspective, a plainText branch of the DSL could ignore the > fieldBridge machinery but I'm not sure it's a good idea. That's why I > would like some feedback about this before moving in this direction. We already do some magic depending on the fieldbridge we have (especially the built-in ones vs custom ones). We might enable some features iif we know the field is built-in and predictable. Or literally if that is the same one. So, if we go and enable different classes of analyzers per field, I think we can solve the AND problem, the stack needs to be separated into: - an tokenizer that splits the stream into words - a set of filters that only normalise the words (lower case, accept, stemming, stop words probably, etc). - a set of filters that inject multiple tokens per initial ?word? (ngrams and synonyms) It is ver possible that the first set of filter is always naturally before the second set of analyzers. Any counter example? With this, we can AND the various words and OR the second stream of tokens (or forbid them initially). We would apply the analysis in two phases. From emmanuel at hibernate.org Tue Mar 4 05:09:32 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 11:09:32 +0100 Subject: [hibernate-dev] [Wildcard] Search: changing the way we search In-Reply-To: References: Message-ID: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> This email is about wildcard On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > > And why is it not ideal: > 3/ wildcard and analyzers are really a pain with Lucene and you need > to implement your own cleaning stuff to get a working wildcard query. > > > IV. About wildcard queries > -------------------------------------- > > Let's say it frankly: wildcard queries are a pain in Lucene. > > Let's take an example: > - You index "Parking" and you have a LowerCaseFilter so your index > contains "parking"; > - You search for Parking without wildcard, it will work; > - You search for Parki* with wildcard, yeah, it won't work. > > This is due to the fact that for wildcards, the analyzers are ignored. > Usually, because if you use ? or *, they can be replaced by the > filters you use in your analyzers. > > While we all understand the Lucene point of view from a technical > perspective, I don't think we can keep this position for Hibernate > Search as a user friendly search framework on top of Hibernate. > > At Open Wide, we have a quite complex method which rewrites a search > as a working autocompletion search which might work most of the time > (with a high value of most...). It's kinda ugly, far from perfect and > I'm wondering if we could have something more clever in Search. I once > talked with Emmanuel about having different analyzers for Indexing, > Querying (this is the Solr way) and Wildcards/Fuzzy search (this is > IMHO a good idea as the way you want to normalize your wildcard query > highly depends on the analyzer used to index your data). I would like to separate the notion of autosuggestion from the wildcard problem. To me they are separate and I would love to Hibernate Search to offer an autosuggest and spell checker API. Back to wildcard. If we have an analyser stack that separates normaliser filters from filters generating additional tokens (see my email [AND]), then it is piece of cake to apply the right filters, raise an exception if someone tries to wildcard on ngrams, and simply ignore the synonym filter. From guillaume.smet at gmail.com Tue Mar 4 06:09:00 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Mar 2014 12:09:00 +0100 Subject: [hibernate-dev] [Wildcard] Search: changing the way we search In-Reply-To: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> References: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> Message-ID: On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard wrote: > I would like to separate the notion of autosuggestion from the wildcard problem. To me they are separate and I would love to Hibernate Search to offer an autosuggest and spell checker API. AFAICS from the changelog of each version, autosuggest is still a vast work in progress in Lucene/Solr. > Back to wildcard. If we have an analyser stack that separates normaliser filters from filters generating additional tokens (see my email [AND]), then it is piece of cake to apply the right filters, raise an exception if someone tries to wildcard on ngrams, and simply ignore the synonym filter. In theory, yes. But for the tokenization, we use WhitespaceTokenizer and WordDelimiterFilter which generates new tokens (for example, depending on the options you use, you can index wi-fi as wi and fi, wi-fi and wifi). The problem of this particular filter is also that we put it after the ASCIIFoldingFilter because we want the input to be as clean as possible but before the LowerCaseFilter as WordDelimiterFilter can do its magic on case change too. If you separate normalizer from tokenizer, I don't think it's going to be easy to order them adequately. From guillaume.smet at gmail.com Tue Mar 4 06:24:09 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Mar 2014 12:24:09 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: Message-ID: Hi Emmanuel, On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard wrote: >> Here are pointers to the main problems I have: >> 1/ the getAllTermsFromText is cute when you want to OR the terms but >> really bad when you need AND, especially when you use analyzers which >> returns several tokens for a term (this is the case when you use the >> SynonymFilter or the WordDelimiterFilter); > > Why do you say "especially"? Isn't it "only" It's been a while, that's why I wasn't categorical. But, as far as I recall from my work back then, I think you're right. >> 2/ the fieldBridge thing is quite painful for plain text search as we >> are not sure that all the fields have the same fieldBridge and, thus, >> the search terms might be different for each fields after applying the >> fieldBridge. > > That would lead to different term queries but on different fields. So I am not sure I follow the problem you are describing. Any chance you can rephrase it? This point is related to the one below. > If I understand you, you wan to find several and words and in and my and content in title or in summary or in content but all terms should be present in one of the field. Is that correct? What's the use case behind? It's probably the most common use case we have. Let's say you have an entity called "Hotel whatever" and in its description it says it does have a swimming pool but the word "hotel" doesn't appear in the description (my example isn't the best chosen but I think you can easily imagine it does happen on real data). Our user is looking for "hotel swimming pool", and we want "Hotel whatever" to match. Of course, if you use a OR with a sort by score, it does work (more or less) but the main issue is that our customers don't want too many unrelated results. They only want items which really match the query. Moreover, they often don't want the results sorted by score so the OR + sort by score approach is really not acceptable. This is why we use MultiFieldQueryParser with AND as the default operator a lot when using Lucene directly and the (e)dismax parser when using Solr. >>> From my perspective, a plainText branch of the DSL could ignore the >> fieldBridge machinery but I'm not sure it's a good idea. That's why I >> would like some feedback about this before moving in this direction. > > We already do some magic depending on the fieldbridge we have (especially the built-in ones vs custom ones). > We might enable some features iif we know the field is built-in and predictable. Or literally if that is the same one. > > So, if we go and enable different classes of analyzers per field, I think we can solve the AND problem, the stack needs to be separated into: > - an tokenizer that splits the stream into words > - a set of filters that only normalise the words (lower case, accept, stemming, stop words probably, etc). > - a set of filters that inject multiple tokens per initial "word" (ngrams and synonyms) > > It is ver possible that the first set of filter is always naturally before the second set of analyzers. Any counter example? > > With this, we can AND the various words and OR the second stream of tokens (or forbid them initially). We would apply the analysis in two phases. See my points in my other email. I'll try to write some code to explain what I would like to do. I'll keep you posted when I have something consistent. -- Guillaume From emmanuel at hibernate.org Tue Mar 4 07:15:37 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 13:15:37 +0100 Subject: [hibernate-dev] [Empty/null] Search: changing the way we search In-Reply-To: References: Message-ID: <9A30F1A8-F557-46D7-8FEC-9E18AD60679A@hibernate.org> On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > 2/ we often need to add a clause only if the text isn't empty or the > object not null and we then need to add more logic than the fluent > approach allows it (I don't have any ideas/proposals for this one but > I think it's worth mentioning). > > > V. The "don't add this clause if null/empty" problem > ---------------------------------------------------------------------------- > > Ideas welcome! > Can you explain with more details the use cases you are thinking about? Maybe a code example of how you would have to do it today. There are two problems I can think of: 1. the DSL tend to die in horrible pain if the input turns out full of stop words or other edge cases like that. We should list and test these 2. the user wants to add the input regardless of the value to make the DSL work at it?s best We might be able to address 2. even though I don?t think this solution covers everything. a. we could be smart and eliminate the boolean query when there is a single clause b. if we could have a marker NoopQuery object, we could silently ignore it and remove it from the boolean clause. The problem with the NoopQuery is that it could mena 3 things: - fail - return nothing - return everything From emmanuel at hibernate.org Tue Mar 4 07:24:32 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 13:24:32 +0100 Subject: [hibernate-dev] [Wildcard] Search: changing the way we search In-Reply-To: References: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> Message-ID: <7BF1B618-FC04-4561-9AD0-7DA10AABB35E@hibernate.org> On 04 Mar 2014, at 12:09, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard > wrote: >> I would like to separate the notion of autosuggestion from the wildcard problem. To me they are separate and I would love to Hibernate Search to offer an autosuggest and spell checker API. > > AFAICS from the changelog of each version, autosuggest is still a vast > work in progress in Lucene/Solr. So? :) > >> Back to wildcard. If we have an analyser stack that separates normaliser filters from filters generating additional tokens (see my email [AND]), then it is piece of cake to apply the right filters, raise an exception if someone tries to wildcard on ngrams, and simply ignore the synonym filter. > > In theory, yes. > > But for the tokenization, we use WhitespaceTokenizer and > WordDelimiterFilter which generates new tokens (for example, depending > on the options you use, you can index wi-fi as wi and fi, wi-fi and > wifi). Ok that poses a problem for the wildcard if wi and if are separated. But I don?t think it?s an issue for the AND case as we would get the expected query: - hotel AND wi-fi - hotel AND wi AND fi And to be fair, how do you plan to make wildcard and wi fi work together in Lucene (any solution available). The solution I can think of is to index the property with an analyzer stack that does not split words like that in two tokens. > > The problem of this particular filter is also that we put it after the > ASCIIFoldingFilter because we want the input to be as clean as > possible but before the LowerCaseFilter as WordDelimiterFilter can do > its magic on case change too. > > If you separate normalizer from tokenizer, I don't think it's going to > be easy to order them adequately. From emmanuel at hibernate.org Tue Mar 4 07:36:51 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 13:36:51 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: Message-ID: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> On 04 Mar 2014, at 12:24, Guillaume Smet wrote: > Hi Emmanuel, > > On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard > wrote: > >> If I understand you, you wan to find several and words and in and my and content in title or in summary or in content but all terms should be present in one of the field. Is that correct? What's the use case behind? > > It's probably the most common use case we have. > > Let's say you have an entity called "Hotel whatever" and in its > description it says it does have a swimming pool but the word "hotel" > doesn't appear in the description (my example isn't the best chosen > but I think you can easily imagine it does happen on real data). > > Our user is looking for "hotel swimming pool", and we want "Hotel > whatever" to match. OK so you want the words hotel + swimming pool to be present somewhere in the sum of the corpus of title and description. That?s the second case I was describing then. Indeed it kinda fails if you don?t order by score but rather alphabetically or by distance. Have you considered the following: your query should only consider the top n, or the results whose score reaches 70% of the top score and then do your business sort on this subset. Anyways, to address this, one need to target fields that are: - using the same fieldbridge - using the same analyzer - do the trick I was describing around filters like ngrams (and then or) From guillaume.smet at gmail.com Tue Mar 4 09:02:23 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Mar 2014 15:02:23 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> Message-ID: On Tue, Mar 4, 2014 at 1:36 PM, Emmanuel Bernard wrote: > OK so you want the words hotel + swimming pool to be present somewhere in the sum of the corpus of title and description. That's the second case I was describing then. Indeed it kinda fails if you don't order by score but rather alphabetically or by distance. > Have you considered the following: your query should only consider the top n, or the results whose score reaches 70% of the top score and then do your business sort on this subset. It doesn't work. Users want the results which really match and we can't have missing results or additional results. They search for something and they want to find exactly what they are looking for. Note: this is really 99.9% of our use cases, probably because we mostly develop business applications. > Anyways, to address this, one need to target fields that are: > - using the same fieldbridge > - using the same analyzer > - do the trick I was describing around filters like ngrams (and then or) That's when I stopped my work on HSEARCH-917. I wasn't sure I could decently require such conditions, at least not in the current API. I started to wonder if we could introduce a text() branch in parallel to keyword() and phrase() but never really posted about it. I would like to separate the user responsibility from the developer responsibility: - the user defines his search query. It's a little more clever than just a term search: he can use + - and "": that's why I would like to use a QueryParser directly (most of our users don't use it but some of them need it); - the developer defines how the search is done: it can search on several fields: for each field, the developer can define a boost (this is supported by the SimpleQueryParser) AND he can also define if it's a fuzzy query (not supported out of the box by the SimpleQueryParser). (we could even imagine to support minimum should match as the dismax parser does) Because, this is really what we need on a daily basis: my user don't really know if his search needs to be fuzzy or not. And I would like to be able to make the decision for him because I know the corpus of documents and I know it's going to be needed. I don't know if it looks like something interesting to you? From guillaume.smet at gmail.com Tue Mar 4 09:07:57 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Mar 2014 15:07:57 +0100 Subject: [hibernate-dev] [Wildcard] Search: changing the way we search In-Reply-To: <7BF1B618-FC04-4561-9AD0-7DA10AABB35E@hibernate.org> References: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> <7BF1B618-FC04-4561-9AD0-7DA10AABB35E@hibernate.org> Message-ID: On Tue, Mar 4, 2014 at 1:24 PM, Emmanuel Bernard wrote: > And to be fair, how do you plan to make wildcard and wi fi work together in Lucene (any solution available). The solution I can think of is to index the property with an analyzer stack that does not split words like that in two tokens. I don't use them for wildcard queries but I do use them for plain text queries and I need to be able to do that in that case. If we define a tokenizer phase then a normalizer phase in the analyzer definition, I won't be able to do so for my plain text queries. Or do you have something more specific to wildcard queries in mind? From emmanuel at hibernate.org Tue Mar 4 11:31:04 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 17:31:04 +0100 Subject: [hibernate-dev] [Wildcard] Search: changing the way we search In-Reply-To: References: <3C69772B-C4F9-45D1-9081-BE648FAE0EEF@hibernate.org> <7BF1B618-FC04-4561-9AD0-7DA10AABB35E@hibernate.org> Message-ID: <22809C63-363F-4BA5-B6B7-8C520AB23290@hibernate.org> On 04 Mar 2014, at 15:07, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 1:24 PM, Emmanuel Bernard wrote: >> And to be fair, how do you plan to make wildcard and wi fi work together in Lucene (any solution available). The solution I can think of is to index the property with an analyzer stack that does not split words like that in two tokens. > > I don't use them for wildcard queries but I do use them for plain text > queries and I need to be able to do that in that case. If we define a > tokenizer phase then a normalizer phase in the analyzer definition, I > won't be able to do so for my plain text queries. Or do you have > something more specific to wildcard queries in mind? I am not quite sure what you are referring to by plain text query. To me that would be qb.keyword().onFields(?title?, ?description?).matching(search).createQuery(); or very close to that. From emmanuel at hibernate.org Tue Mar 4 12:05:07 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 18:05:07 +0100 Subject: [hibernate-dev] Team meeting minutes Message-ID: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> Here are the meeting minutes. I did add a manual summary since I don?t know how to effectively use the bot to its full potential. ## Validator 5.1 is out and plan to push it to WildFly as soon as they permit. ## Search ### MoreLikeThis Functional enough MoreLikeThis is out. Emmanuel needs to open JIRa issues for the remaining work Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution ### Release Release 5.0 Alpha 2 planned for Wednesday. Still need: - HSEARCH-1513 - maybe HSEARCH-1508 Keep an eye on Infinispan 7 changes to be able to roll back to 6 if schedule clash ### Roadmap Sanne to update http://hibernate.org/search/roadmap/ or JIRA with tiered focus to reach 5.0 final Sanne to place dates for each of these milestones to keep us honest. Might be kept team private to avoid noise. Sanne to steal a bit of Brett?s time from Steve around OSGi ### free-form Emmanuel to focus next on free-form as soon as mininal work on MLT is done (identified embedded elements) ## OGM Worked on Wildfly module bug (protected visibility). Davide to move forward to patch ORM to remove the OGM code duplication. Redis is Davide?s relaxation task. ### Neo4J Davide to focus on Neo4J (rebase, remote support and query support) ### Next release With Gunnar soon going dark (holiday and preparation for summit, things are a bit undefined. All bets on Neo4J and Davide Gunnar focuses on closing near-ending tasks by end of week (incl Adrian?s PR) ### Longer term Gunnar to explore optimisation related to embedded associations Gunnar to explore recovery API ### Emmanuel Not planning to work actively on a OGM features in the next 2 months. Negotiable. Working on Search has priority. ## CI Instabilities seen on Search should be gone now. ## Summit Gunnar and Sanne might be busy preparing Summit for a week. That?ll be a toll of 2 weeks off main project work. ## ORM Lots of very intimate back patting going on around performance improvement. Someone needs to take the lead and write a blog post on 4.2 vs 4.3 perf wise and the performance improvements tricks used. ## Full Minutes Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.log.html From emmanuel at hibernate.org Tue Mar 4 12:27:19 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 18:27:19 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> Message-ID: <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> On 04 Mar 2014, at 15:02, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 1:36 PM, Emmanuel Bernard wrote: >> OK so you want the words hotel + swimming pool to be present somewhere in the sum of the corpus of title and description. That's the second case I was describing then. Indeed it kinda fails if you don't order by score but rather alphabetically or by distance. >> Have you considered the following: your query should only consider the top n, or the results whose score reaches 70% of the top score and then do your business sort on this subset. > > It doesn't work. Users want the results which really match and we > can't have missing results or additional results. > > They search for something and they want to find exactly what they are > looking for. > > Note: this is really 99.9% of our use cases, probably because we > mostly develop business applications. > >> Anyways, to address this, one need to target fields that are: >> - using the same fieldbridge >> - using the same analyzer >> - do the trick I was describing around filters like ngrams (and then or) > > That's when I stopped my work on HSEARCH-917. I wasn't sure I could > decently require such conditions, at least not in the current API. > > I started to wonder if we could introduce a text() branch in parallel > to keyword() and phrase() but never really posted about it. > > I would like to separate the user responsibility from the developer > responsibility: > - the user defines his search query. It's a little more clever than > just a term search: he can use + - and "": that's why I would like to > use a QueryParser directly (most of our users don't use it but some of > them need it); > - the developer defines how the search is done: it can search on > several fields: for each field, the developer can define a boost (this > is supported by the SimpleQueryParser) AND he can also define if it's > a fuzzy query (not supported out of the box by the SimpleQueryParser). > (we could even imagine to support minimum should match as the dismax > parser does) > > Because, this is really what we need on a daily basis: my user don't > really know if his search needs to be fuzzy or not. And I would like > to be able to make the decision for him because I know the corpus of > documents and I know it's going to be needed. > > I don't know if it looks like something interesting to you? Yes a text() branch injecting whatever from the user and letting the developer customise what needs to be searched makes sense to me. We can explore that but I am a bit skeptical that it will turn into a true `text()` clause rather than be a bit more friendly in other branches of the DSL. I?m happy to be proven wrong. But I am a bit confused and would love some code example to start from (as in doing what is required). searchInput From guillaume.smet at gmail.com Tue Mar 4 13:06:17 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Mar 2014 19:06:17 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> Message-ID: On Tue, Mar 4, 2014 at 6:27 PM, Emmanuel Bernard wrote: > Yes a text() branch injecting whatever from the user and letting the developer customise what needs to be searched makes sense to me. > We can explore that but I am a bit skeptical that it will turn into a true `text()` clause rather than be a bit more friendly in other branches of the DSL. > I'm happy to be proven wrong. But I am a bit confused and would love some code example to start from (as in doing what is required). I think we mostly agree. It's just that I don't know if we'll find an acceptable way to change the behavior of the keyword() branch without breaking any applications out there. I'll post as soon as I have a working prototype of what I would like to achieve and then we can discuss from there. From gunnar at hibernate.org Tue Mar 4 12:45:56 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 4 Mar 2014 18:45:56 +0100 Subject: [hibernate-dev] Team meeting minutes In-Reply-To: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> References: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> Message-ID: 2014-03-04 18:05 GMT+01:00 Emmanuel Bernard : ## ORM > > Lots of very intimate back patting going on around performance improvement. > LOL. Was this your test whether anyone would be reading up to here :) From hardy at hibernate.org Tue Mar 4 14:32:17 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 4 Mar 2014 20:32:17 +0100 Subject: [hibernate-dev] Team meeting minutes In-Reply-To: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> References: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> Message-ID: On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > Here are the meeting minutes. > I did add a manual summary since I don?t know how to effectively use the bot to its full potential. > > ## Validator > > 5.1 is out and plan to push it to WildFly as soon as they permit. I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 It is actually already merged. Not sure why the issue is not marked as such yet. > ## Search > > ### MoreLikeThis > > Functional enough MoreLikeThis is out. > Emmanuel needs to open JIRa issues for the remaining work > Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution ### ClassLoaderService I am almost ready with the ClassLoaderService stuff. My working branch https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 is compiling, rebased on top of current master and passing all tests. I still have a couple of TODOs to address, but it should be ready to be merged in a bit. Feel free to have a look and provide feedback. Once I am ready with this I will look into the upgrade to Lucene 4.7, mainly because the upgrade affects mainly the faceting code. Gives me also another reason to get back into this ;-) ?Hardy From smarlow at redhat.com Tue Mar 4 14:41:53 2014 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 04 Mar 2014 14:41:53 -0500 Subject: [hibernate-dev] Team meeting minutes In-Reply-To: References: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> Message-ID: <53162C81.8070508@redhat.com> On 03/04/2014 02:32 PM, Hardy Ferentschik wrote: > > On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > >> Here are the meeting minutes. >> I did add a manual summary since I don?t know how to effectively use the bot to its full potential. >> >> ## Validator >> >> 5.1 is out and plan to push it to WildFly as soon as they permit. > > I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 > It is actually already merged. Not sure why the issue is not marked as such yet. I just closed it. After the WildFly committer merges the change, they usually don't update the jira. > >> ## Search >> >> ### MoreLikeThis >> >> Functional enough MoreLikeThis is out. >> Emmanuel needs to open JIRa issues for the remaining work >> Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution > > ### ClassLoaderService > > I am almost ready with the ClassLoaderService stuff. My working branch https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 > is compiling, rebased on top of current master and passing all tests. I still have a couple of TODOs to address, but it should be ready to be merged > in a bit. Feel free to have a look and provide feedback. > > Once I am ready with this I will look into the upgrade to Lucene 4.7, mainly because the upgrade affects mainly the faceting code. > Gives me also another reason to get back into this ;-) > > ?Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Tue Mar 4 14:50:27 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 4 Mar 2014 20:50:27 +0100 Subject: [hibernate-dev] Team meeting minutes In-Reply-To: <53162C81.8070508@redhat.com> References: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> <53162C81.8070508@redhat.com> Message-ID: <6CF2B20B-8CEC-4C7E-A14E-C96EBE8600DF@hibernate.org> On 4 Jan 2014, at 20:41, Scott Marlow wrote: > On 03/04/2014 02:32 PM, Hardy Ferentschik wrote: >> >> On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: >> >>> Here are the meeting minutes. >>> I did add a manual summary since I don?t know how to effectively use the bot to its full potential. >>> >>> ## Validator >>> >>> 5.1 is out and plan to push it to WildFly as soon as they permit. >> >> I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 >> It is actually already merged. Not sure why the issue is not marked as such yet. > > I just closed it. After the WildFly committer merges the change, they usually don't update the jira. I see. Good to know. ?Hardy From emmanuel at hibernate.org Tue Mar 4 17:04:43 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 4 Mar 2014 23:04:43 +0100 Subject: [hibernate-dev] Team meeting minutes In-Reply-To: References: <0E4FC9AE-9B4B-4673-9C1A-04FF54795728@hibernate.org> Message-ID: <20140304220443.GD31430@hibernate.org> On Tue 2014-03-04 20:32, Hardy Ferentschik wrote: > > On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > > > Here are the meeting minutes. > > I did add a manual summary since I don?t know how to effectively use the bot to its full potential. > > > > ## Validator > > > > 5.1 is out and plan to push it to WildFly as soon as they permit. > > I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 > It is actually already merged. Not sure why the issue is not marked as such yet. > > > ## Search > > > > ### MoreLikeThis > > > > Functional enough MoreLikeThis is out. > > Emmanuel needs to open JIRa issues for the remaining work > > Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution > > ### ClassLoaderService > > I am almost ready with the ClassLoaderService stuff. My working branch https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 > is compiling, rebased on top of current master and passing all tests. I still have a couple of TODOs to address, but it should be ready to be merged > in a bit. Feel free to have a look and provide feedback. Sweet :) From sanne at hibernate.org Wed Mar 5 09:48:20 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 5 Mar 2014 14:48:20 +0000 Subject: [hibernate-dev] Hibernate Search 5.0.0.Alpha2 now available Message-ID: Just released! http://in.relation.to/Bloggers/SecondMilestoneTowardsHibernateSearch5IntroducingMoreLikeThisQueries -- Sanne From steve at hibernate.org Wed Mar 5 12:40:01 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Mar 2014 11:40:01 -0600 Subject: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor Message-ID: Historically annotation binding within Hibernate made a huge assumption that AccessType and PropertyAccessor were the same thing. They aren't necessarily. AccessType is simply meant to dictate where to look for annotations relating to "persistent attributes". PropertyAccessor is Hibernate's way of accessing property values (getting/setting) at runtime. Granted, AccessType *by default* should indicate the PropertyAccessor to use. I am not arguing that. I am just suggesting that we should keep both as distinct values. At the moment we collapse them into a single String (we dump AccessType and keep "PropertyAccessor name"). The trouble is that later on we sometimes need to know the AccessType, at which point we are forced to make a guess by interpreting the PropertyAccessor in use and hoping that a custom PropertyAccessor was not supplied. Keeping these as distinct values alleviates that. Thoughts? From thomas.jones-low at foundationdb.com Wed Mar 5 13:17:43 2014 From: thomas.jones-low at foundationdb.com (Thomas Jones-Low) Date: Wed, 05 Mar 2014 13:17:43 -0500 Subject: [hibernate-dev] GeneratedIdColumnHbmTests#testNativeId test fails with dialect supporting both IDENTITY and SEQUNCES Message-ID: <53176A47.7060301@foundationdb.com> I'm building a new dialect for the FoundationDB SQL layer. I've merged in the recent metamodel merge into my working branch and ran across this new failure. GeneratedIdColumnHbmTests#testNativeId() fails with an assertion error. This is caused by entityBinding.getPrimaryTable().getPrimaryKey().getColumns().get( 0 ).isIdentity() returns false, which is should return true. The only place the column.isIdentity() is set true is in org.hibernate.metamodel.internal.Binder#bindIdentifierGenerator(line 1491). And this is based upon if the entityIdentifier.getIdentifierGenerator(), which in turn delegates to Dialect#getNativeIdentifierGeneratorClass(), returns an IdentityGenerator.class The problem here is that a dialect can support IDENTITY column, but not use (or return) IdentityGenerator from the getNativeIdentifierClass(). FoundationdDB SQL layer supports both IDENTITY and sequences, as does the PostgreSQLDialect. Is this a bug in Binder? that the test should be better formed to set the identity column. Is this a new limitation on Dialects, in that they can no longer correctly support both IDENTITY and sequences? What is the correct way to fix this problem? From steve at hibernate.org Wed Mar 5 15:09:16 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 5 Mar 2014 14:09:16 -0600 Subject: [hibernate-dev] GitHub links in Jira Message-ID: If you notice GitHub links no longer available from issues... well you aren't alone :) After then most recent Jira OnDemand update to 6.2 something went screwy in our DVCS set up. I have engaged Atlassian to help sort it out. From hardy at hibernate.org Thu Mar 6 05:30:21 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 6 Mar 2014 11:30:21 +0100 Subject: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor In-Reply-To: References: Message-ID: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> On 5 Jan 2014, at 18:40, Steve Ebersole wrote: > Historically annotation binding within Hibernate made a huge assumption > that AccessType and PropertyAccessor were the same thing. They aren't > necessarily. AccessType is simply meant to dictate where to look for > annotations relating to "persistent attributes". PropertyAccessor is > Hibernate's way of accessing property values (getting/setting) at runtime. > > Granted, AccessType *by default* should indicate the PropertyAccessor to > use. I am not arguing that. I am just suggesting that we should keep both > as distinct values. At the moment we collapse them into a single String > (we dump AccessType and keep "PropertyAccessor name"). > > The trouble is that later on we sometimes need to know the AccessType, at > which point we are forced to make a guess by interpreting the > PropertyAccessor in use and hoping that a custom PropertyAccessor was not > supplied. I don?t know where it is exactly where you need the distinction, but if you do, I also think they should be kept separated. Also having distinct concepts for this maybe makes concepts also a bit clearer. +1 from me ?Hardy From emmanuel at hibernate.org Thu Mar 6 07:22:31 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 6 Mar 2014 13:22:31 +0100 Subject: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor In-Reply-To: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> References: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> Message-ID: <20140306122231.GK31430@hibernate.org> On Thu 2014-03-06 11:30, Hardy Ferentschik wrote: > > On 5 Jan 2014, at 18:40, Steve Ebersole wrote: > > > Historically annotation binding within Hibernate made a huge assumption > > that AccessType and PropertyAccessor were the same thing. They aren't > > necessarily. AccessType is simply meant to dictate where to look for > > annotations relating to "persistent attributes". PropertyAccessor is > > Hibernate's way of accessing property values (getting/setting) at runtime. > > > > Granted, AccessType *by default* should indicate the PropertyAccessor to > > use. I am not arguing that. I am just suggesting that we should keep both > > as distinct values. At the moment we collapse them into a single String > > (we dump AccessType and keep "PropertyAccessor name"). > > > > The trouble is that later on we sometimes need to know the AccessType, at > > which point we are forced to make a guess by interpreting the > > PropertyAccessor in use and hoping that a custom PropertyAccessor was not > > supplied. > > I don?t know where it is exactly where you need the distinction, but if you do, > I also think they should be kept separated. Also having distinct concepts for this maybe > makes concepts also a bit clearer. AccessType in JPA means both but is also much more limited than our PropertyAccessor approach. If your plan is to separate them in the metamodel, then +1 and if propertyAccessor is not set, fall back to JPA's default behavior. From mcdimus at gmail.com Thu Mar 6 10:50:11 2014 From: mcdimus at gmail.com (Dmitri Maksimov) Date: Thu, 6 Mar 2014 17:50:11 +0200 Subject: [hibernate-dev] Participation in GSoC 2014 Message-ID: Hello! I am writing this letter as I would like to participate in GSoC 2014 developing the following idea: "Bringing the goodness of Java 8 to Hibernate Validator". I had a conversation with Gunnar Morling and he suggested to write an introductory letter to this mailing list. My name is Dmitri Maksimov. I am a Master's degree programme in Informatics student at Tallinn University of Technology. Java is a primary programming language in our university, thus I have learned/tried a lot of stuff from Java itself (such as multithreading, reflection, custom classloaders etc.) and some corresponding tools and frameworks (Spring, Hibernate etc.). Currently I am employed as a Java developer and I am developing web-based GUI using JavaEE 6, JSF + CDI (Weld implementation) for some SOAP service. Input data validation is quite important for the GUI, so occasionally I found out about JSR-303/JSR-349 and Hibernate Validator and I thinks it is great. So, why am I applying for this idea? I have a true interest, strong knowledge and some work experience in Java platform. I really would like to use the chance to gain real-world experience in using new Java 8 features as well as get more experience with Java as general. I like the idea and principles of JSR-303/JSR-349 and Hibernate Validator. I will gladly answer any questions if necessary. And I look forward to hear what you think. -- Yours faithfully, Dmitri Maksimov. From steve at hibernate.org Thu Mar 6 17:57:47 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Mar 2014 16:57:47 -0600 Subject: [hibernate-dev] GitHub links in Jira In-Reply-To: References: Message-ID: Ok, its there now. Look off to the far right now on issues (that have commits or pull requests) On Wed, Mar 5, 2014 at 2:09 PM, Steve Ebersole wrote: > If you notice GitHub links no longer available from issues... well you > aren't alone :) > > After then most recent Jira OnDemand update to 6.2 something went screwy > in our DVCS set up. I have engaged Atlassian to help sort it out. > From steve at hibernate.org Thu Mar 6 18:09:23 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 6 Mar 2014 17:09:23 -0600 Subject: [hibernate-dev] GitHub links in Jira In-Reply-To: References: Message-ID: OK, well it *should* show up for issues with Pull Requests in GitHub. That may not be working atm based on the quick 2 i looked at On Thu, Mar 6, 2014 at 4:57 PM, Steve Ebersole wrote: > Ok, its there now. Look off to the far right now on issues (that have > commits or pull requests) > > > On Wed, Mar 5, 2014 at 2:09 PM, Steve Ebersole wrote: > >> If you notice GitHub links no longer available from issues... well you >> aren't alone :) >> >> After then most recent Jira OnDemand update to 6.2 something went screwy >> in our DVCS set up. I have engaged Atlassian to help sort it out. >> > > From guillaume.smet at hibernate.org Fri Mar 7 05:52:59 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Fri, 7 Mar 2014 11:52:59 +0100 Subject: [hibernate-dev] ClassCastException with 2nd level cache not entirely gone? Message-ID: Hi all, We just hit the ClassCastException problem with 2nd level cache reported by other people. But... we're using *4.3.4.Final* so I'm not sure this issue has really been fixed with 4.3.4.Final. Typically, we have the following hierarchy: AbstractUser TechnicalUser (id = 1) AccountManager (id = 2) entityManager.find(AccountManager.class, 1) returns the TechnicalUser 1 and not null if the 2nd level cache is enabled (and the object is in the cache). I'm pretty sure it's not the expected behavior. Should I open a JIRA issue or do you prefer to reopen an existing issue? I'm not entirely sure it's due to the same problem so I thought I might as well ask here. Thanks for your feedback. -- Guillaume From sanne at hibernate.org Fri Mar 7 06:05:39 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 7 Mar 2014 11:05:39 +0000 Subject: [hibernate-dev] ClassCastException with 2nd level cache not entirely gone? In-Reply-To: References: Message-ID: Hi Guillaume, thanks for the timely notice: that's critical. Please open a new issue, we usually don't reopen issues which where already included in some release. On 7 March 2014 10:52, Guillaume Smet wrote: > Hi all, > > We just hit the ClassCastException problem with 2nd level cache > reported by other people. > > But... we're using *4.3.4.Final* so I'm not sure this issue has really > been fixed with 4.3.4.Final. > > Typically, we have the following hierarchy: > AbstractUser > TechnicalUser (id = 1) > AccountManager (id = 2) > > entityManager.find(AccountManager.class, 1) returns the TechnicalUser > 1 and not null if the 2nd level cache is enabled (and the object is in > the cache). > > I'm pretty sure it's not the expected behavior. > > Should I open a JIRA issue or do you prefer to reopen an existing > issue? I'm not entirely sure it's due to the same problem so I thought > I might as well ask here. > > Thanks for your feedback. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Fri Mar 7 06:12:00 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 7 Mar 2014 12:12:00 +0100 Subject: [hibernate-dev] ClassCastException with 2nd level cache not entirely gone? In-Reply-To: References: Message-ID: Hi Sanne, On Fri, Mar 7, 2014 at 12:05 PM, Sanne Grinovero wrote: > thanks for the timely notice: that's critical. Please open a new > issue, we usually don't reopen issues which where already included in > some release. Thanks for you quick feedback. Done: https://hibernate.atlassian.net/browse/HHH-9028 -- Guillaume From guillaume.smet at gmail.com Fri Mar 7 09:36:25 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 7 Mar 2014 15:36:25 +0100 Subject: [hibernate-dev] ClassCastException with 2nd level cache not entirely gone? In-Reply-To: References: Message-ID: On Fri, Mar 7, 2014 at 12:12 PM, Guillaume Smet wrote: > https://hibernate.atlassian.net/browse/HHH-9028 FWIW, I posted a test case and a patch proposal. -- Guillaume From guillaume.smet at hibernate.org Fri Mar 7 10:02:53 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Fri, 7 Mar 2014 16:02:53 +0100 Subject: [hibernate-dev] Code templates empty on "Contributing to Hibernate using Eclipse" page Message-ID: Hi, I already mentioned it here a while ago: the code-templates.xml file at the bottom of https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse is empty. IIRC, it should at least contain the Copyright header? Thanks! -- Guillaume From gbadner at redhat.com Fri Mar 7 13:31:47 2014 From: gbadner at redhat.com (Gail Badner) Date: Fri, 7 Mar 2014 13:31:47 -0500 (EST) Subject: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor In-Reply-To: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> References: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> Message-ID: <1444533119.16001575.1394217107290.JavaMail.zimbra@redhat.com> +1 for separating. ----- Original Message ----- > From: "Hardy Ferentschik" > To: "Steve Ebersole" > Cc: "Hibernate" > Sent: Thursday, March 6, 2014 2:30:21 AM > Subject: Re: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor > > > On 5 Jan 2014, at 18:40, Steve Ebersole wrote: > > > Historically annotation binding within Hibernate made a huge assumption > > that AccessType and PropertyAccessor were the same thing. They aren't > > necessarily. AccessType is simply meant to dictate where to look for > > annotations relating to "persistent attributes". PropertyAccessor is > > Hibernate's way of accessing property values (getting/setting) at runtime. > > > > Granted, AccessType *by default* should indicate the PropertyAccessor to > > use. I am not arguing that. I am just suggesting that we should keep both > > as distinct values. At the moment we collapse them into a single String > > (we dump AccessType and keep "PropertyAccessor name"). > > > > The trouble is that later on we sometimes need to know the AccessType, at > > which point we are forced to make a guess by interpreting the > > PropertyAccessor in use and hoping that a custom PropertyAccessor was not > > supplied. > > I don?t know where it is exactly where you need the distinction, but if you > do, > I also think they should be kept separated. Also having distinct concepts for > this maybe > makes concepts also a bit clearer. > > +1 from me > > ?Hardy > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Sun Mar 9 12:20:42 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 9 Mar 2014 11:20:42 -0500 Subject: [hibernate-dev] Code templates empty on "Contributing to Hibernate using Eclipse" page In-Reply-To: References: Message-ID: Yes, it should. Could someone that actually works with Eclipse fix that? Sanne you seem to be the only one updating this page; could you maybe upload yours? Or Brett, I know you use Eclipse off/on, could you? On Fri, Mar 7, 2014 at 9:02 AM, Guillaume Smet wrote: > Hi, > > I already mentioned it here a while ago: the code-templates.xml file > at the bottom of > https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse > is empty. > > IIRC, it should at least contain the Copyright header? > > Thanks! > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Sun Mar 9 12:41:45 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 9 Mar 2014 11:41:45 -0500 Subject: [hibernate-dev] Separating javax.persistence.AccessType and org.hibernate.property.PropertyAccessor In-Reply-To: <20140306122231.GK31430@hibernate.org> References: <7E262FF2-D474-4836-BDF2-90A61C494D93@hibernate.org> <20140306122231.GK31430@hibernate.org> Message-ID: > > AccessType in JPA means both but is also much more limited than our > PropertyAccessor approach. If your plan is to separate them in the > metamodel, then +1 and if propertyAccessor is not set, fall back to > JPA's default behavior. > What I mean is that currently we utterly have no internal support for recognizing: @Access(FIELD) @AttributeAccessor("property") ... private String someAttribute; which is perfectly valid (aka, look to the field for annotations, but at runtime access getter/setters). There are really 2 questions here in Hibernate terminology. As you say, JPA simply condenses that to one and limits it. The idea of AccessType (where to look for annotations) is what it is; Hibernate's PropertyAccessor contract (AttributeAccessor annotation) has no bearing on that. Given a missing AttributeAccessor annotation, we will default the PropertyAccessor based on the attribute's AccessType. > I don't know where it is exactly where you need the distinction, but if you do, > I also think they should be kept separated. Also having distinct concepts for this maybe > makes concepts also a bit clearer. Right, aside from cleanliness/correctness, one place at least where I have seen it be problematic is in building the JPA metamodel. One thing we are supposed to return is the "java member" for the attribute (javax.persistence.metamodel.Attribute#getJavaMember). I guess it is somewhat arguable given that the spec does not describe what exactly is expected here. Which is not surprising since the spec condenses both concepts together. But I'd think that the more correct return there is the "annotated member". Which is exactly opposite of what we do today when these conflict. From steve at hibernate.org Sun Mar 9 13:31:13 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 9 Mar 2014 12:31:13 -0500 Subject: [hibernate-dev] Possibly interesting use of Jandex Message-ID: As I move through the metamodel code, I try to keep an eye on things we want to do eventually and where/how they might fit in the new mapping processing and binding code. One of the changes we are going through is the move to Jandex. Mainly we are using Jandex for its "annotation indexing" capabilities. But Jandex also has some limited ability to query class relationships, mainly in terms of hierarchies. For example, Jandex lets you ask for all classes that are extensions of a given class or for all classes that are implementations of a given interface. This last part combined in my head with a previous discussion we have had with regard to "dynamic models". The idea was to support generic contracts on the Hibernate Session interface. The main difficulty there being in how @Proxy is handled internally versus on the API. Given an entity like: @Entity @Proxy(proxyClass=Employee.class) class EmployeeImpl implements Employee { ... } the problem is the attempt to type the return of, e.g., Session#get based on the Class parameter passed in because atm you'd have to pass in EmployeeImpl.. but the result would not necessarily be castable to EmployeeImpl. The "simple" solution for this is to allow some form of call where the Employee interface is passed in rather than the EmployeeImpl class. Internally this most likely means a cross reference from Employee ->Persister just like we already do for EmployeeImpl->Persister. We'd want to be VERY sure there is only one impl per interface in this model. Jandex can help there. Not sure how to best handle "persistent inheritance" and especially middle types. I think the difference between org.jboss.jandex.IndexView#getKnownDirectImplementors and org.jboss.jandex.IndexView#getAllKnownImplementors can be leveraged here. Then we had expanded the previous discussion to look at the more general case... interface based models. Imo, the best way to map the above model would be: @Entity interface Employee { ... } Yes, this deviates from JPA which explicitly says that only classes can be annotated. The question is whether we think its worthy of a "vendor extension". This mapping could be interpreted in one of 2 ways: 1) We assume that there is a class that implements this interface (EmployeeImpl) and use that as the concrete class. A lot of the discussion previously was how to "bind" the interface and the concrete class. Again, Jandex can help us there by telling us about "known implementors". More than one would be an error I guess. 2) We'd dynamically generate a class to back this. This generated class can contain many of the performance tweaks we've been developing via bytecode extensions (inline dirty-checking, "entity entry" info, etc). Note that many of the "Jandex can help us" statements make an assumption that Jandex knows about all the classes we are interested in. In the WildFly/Jipijapa deployment case that is not a problem. In other scenarios it is something to be mindful of since we'd need to properly feed the indexer (which is a concern anyway outside of this discussion). From gunnar at hibernate.org Mon Mar 10 04:17:29 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 10 Mar 2014 09:17:29 +0100 Subject: [hibernate-dev] Participation in GSoC 2014 In-Reply-To: References: Message-ID: Hi Dmitri, Many thanks for your interest in the project and the nice introduction. Hardy and I had short first discussion about HV and Java 8 at the corresponding JIRA issue [1]. If you like join the discussion there, any input is highly welcome. One of the big challenges is how to address this issue while keeping compatibility with older Java runtimes (we won't be able to expect Java 8 on every client for quite a long time). An obvious solution is a separate branch of the entire code base, but this wouldn't be so nice from a maintainability perspective. Maybe we could make those parts affected by the change "pluggable" and plug in different implementations depending on the Java version? A related topic is the integration of Bean Validation with JavaFX (the current idea only mentions this shortly). On can use BV in JavaFX already today, but there may be ways for making it more easily usable. Other things are not working yet at all (e.g. applying class-level constraints before the input data has been propagated from the "form" to the data model). Not sure whether this all should be part of one proposal or better two. I'm providing it here as food for thought :) --Gunnar [1] https://hibernate.atlassian.net/browse/HV-825 2014-03-06 16:50 GMT+01:00 Dmitri Maksimov : > Hello! > > I am writing this letter as I would like to participate in GSoC 2014 > developing the following idea: "Bringing the goodness of Java 8 to > Hibernate Validator". I had a conversation with Gunnar Morling and he > suggested to write an introductory letter to this mailing list. > > My name is Dmitri Maksimov. I am a Master's degree programme in Informatics > student at Tallinn University of Technology. Java is a primary programming > language in our university, thus I have learned/tried a lot of stuff from > Java itself (such as multithreading, reflection, custom classloaders etc.) > and some corresponding tools and frameworks (Spring, Hibernate etc.). > > Currently I am employed as a Java developer and I am developing web-based > GUI using JavaEE 6, JSF + CDI (Weld implementation) for some SOAP service. > Input data validation is quite important for the GUI, so occasionally I > found out about JSR-303/JSR-349 and Hibernate Validator and I thinks it is > great. > > So, why am I applying for this idea? > I have a true interest, strong knowledge and some work experience in Java > platform. > I really would like to use the chance to gain real-world experience in > using new Java 8 features as well as get more experience with Java as > general. > I like the idea and principles of JSR-303/JSR-349 and Hibernate Validator. > > I will gladly answer any questions if necessary. And I look forward to hear > what you think. > > > -- > Yours faithfully, > Dmitri Maksimov. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Mon Mar 10 07:59:45 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 10 Mar 2014 12:59:45 +0100 Subject: [hibernate-dev] Storing values at the session level Message-ID: Hi, I'm looking into ways for reducing the number of datastore roundtrips in OGM [1]. One idea is to fetch associations embedded within entity documents (e.g. in MongoDB) when loading such document. We'd "remember" the entity document and could later on retrieve the association from it without going to the store a second time. The problem is the "remembering" part. There is no session-scoped storage facility as of today which I could use. I contemplated making OgmSession deal with this, but I can't access that from persisters etc. Instead I'm seeing the wrapped SessionImpl (to which OgmSession delegates for many operations) and I couldn't find a way to reach the wrapping OgmSession instance. Now I noticed the concept of "SessionOwner" in SessionImpl and am wondering whether I could make use of this. When creating the SessionImpl, I could pass the OgmSession as owner and have it maintain a session-scoped storage. Unfortunately there is no getter for the session owner on SessionFactoryImplementor, though. Would it be feasible to add this getter and thus make a session's owner accessible? Or is there any other (better) way to achieve what I described? Many thanks, --Gunnar [1] https://hibernate.atlassian.net/browse/OGM-469 From emmanuel at hibernate.org Mon Mar 10 08:29:08 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 10 Mar 2014 13:29:08 +0100 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: References: Message-ID: <32809A12-195B-49B9-B3C5-ACAA4A477034@hibernate.org> Either this or have on the session owner contract a generic facility to store session specific data that OGM could extend. I think Steve has been reluctant of such contract in the past. We could re discuss the pluses and minuses. Another alternative is to use transactions as the payload transport. But the synchronization concept does not let you lookup for data outside the before and after tx events. Emmanuel > On 10 mars 2014, at 12:59, Gunnar Morling wrote: > > Hi, > > I'm looking into ways for reducing the number of datastore roundtrips in > OGM [1]. > > One idea is to fetch associations embedded within entity documents (e.g. in > MongoDB) when loading such document. We'd "remember" the entity document > and could later on retrieve the association from it without going to the > store a second time. > > The problem is the "remembering" part. There is no session-scoped storage > facility as of today which I could use. I contemplated making OgmSession > deal with this, but I can't access that from persisters etc. Instead I'm > seeing the wrapped SessionImpl (to which OgmSession delegates for many > operations) and I couldn't find a way to reach the wrapping OgmSession > instance. > > Now I noticed the concept of "SessionOwner" in SessionImpl and am wondering > whether I could make use of this. When creating the SessionImpl, I could > pass the OgmSession as owner and have it maintain a session-scoped storage. > Unfortunately there is no getter for the session owner on > SessionFactoryImplementor, though. > > Would it be feasible to add this getter and thus make a session's owner > accessible? Or is there any other (better) way to achieve what I described? > > Many thanks, > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/OGM-469 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Mar 10 08:32:45 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 10 Mar 2014 13:32:45 +0100 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: References: Message-ID: Minor correction: > Unfortunately there is no getter for the session owner on SessionFactoryImplementor s/SessionFactoryImplementor/SessionImplementor --Gunnar 2014-03-10 12:59 GMT+01:00 Gunnar Morling : > Hi, > > I'm looking into ways for reducing the number of datastore roundtrips in > OGM [1]. > > One idea is to fetch associations embedded within entity documents (e.g. > in MongoDB) when loading such document. We'd "remember" the entity document > and could later on retrieve the association from it without going to the > store a second time. > > The problem is the "remembering" part. There is no session-scoped storage > facility as of today which I could use. I contemplated making OgmSession > deal with this, but I can't access that from persisters etc. Instead I'm > seeing the wrapped SessionImpl (to which OgmSession delegates for many > operations) and I couldn't find a way to reach the wrapping OgmSession > instance. > > Now I noticed the concept of "SessionOwner" in SessionImpl and am > wondering whether I could make use of this. When creating the SessionImpl, > I could pass the OgmSession as owner and have it maintain a session-scoped > storage. Unfortunately there is no getter for the session owner on > SessionFactoryImplementor, though. > > Would it be feasible to add this getter and thus make a session's owner > accessible? Or is there any other (better) way to achieve what I described? > > Many thanks, > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/OGM-469 > > From sanne at hibernate.org Mon Mar 10 11:24:57 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 10 Mar 2014 15:24:57 +0000 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: References: Message-ID: This seems like related to the relation-walking optimization we discussed for Neo4J: also would need to couple the entity instance to the Neo4J document. Currently the Neo4J griddialect would need to run a new query for a graph-traversal: not taking advantage of the graph capabilities which is of course a problem. In Hibernate ORM the EntityEntry stores an array with the loaded values from SQL, needed for some of its state handling. I'd say we should have a way to store data related to extension points into this EntityEntry. If we made this as a general purpose enhancement of ORM, we could maybe have it abstract the storage of the additional attributes into, for example, the enhanced entity class definitions: it would add a field directly to the Entity instance for you to store such an object. There where some chats about maybe doing such an optimization anyway, driven by the performance work. Sanne On 10 March 2014 12:32, Gunnar Morling wrote: > Minor correction: > >> Unfortunately there is no getter for the session owner on > SessionFactoryImplementor > > s/SessionFactoryImplementor/SessionImplementor > > --Gunnar > > > > > 2014-03-10 12:59 GMT+01:00 Gunnar Morling : > >> Hi, >> >> I'm looking into ways for reducing the number of datastore roundtrips in >> OGM [1]. >> >> One idea is to fetch associations embedded within entity documents (e.g. >> in MongoDB) when loading such document. We'd "remember" the entity document >> and could later on retrieve the association from it without going to the >> store a second time. >> >> The problem is the "remembering" part. There is no session-scoped storage >> facility as of today which I could use. I contemplated making OgmSession >> deal with this, but I can't access that from persisters etc. Instead I'm >> seeing the wrapped SessionImpl (to which OgmSession delegates for many >> operations) and I couldn't find a way to reach the wrapping OgmSession >> instance. >> >> Now I noticed the concept of "SessionOwner" in SessionImpl and am >> wondering whether I could make use of this. When creating the SessionImpl, >> I could pass the OgmSession as owner and have it maintain a session-scoped >> storage. Unfortunately there is no getter for the session owner on >> SessionFactoryImplementor, though. >> >> Would it be feasible to add this getter and thus make a session's owner >> accessible? Or is there any other (better) way to achieve what I described? >> >> Many thanks, >> >> --Gunnar >> >> [1] https://hibernate.atlassian.net/browse/OGM-469 >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From brmeyer at redhat.com Mon Mar 10 11:26:06 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 10 Mar 2014 11:26:06 -0400 (EDT) Subject: [hibernate-dev] Code templates empty on "Contributing to Hibernate using Eclipse" page In-Reply-To: References: Message-ID: <235386318.24186313.1394465166548.JavaMail.zimbra@redhat.com> Done! Thanks for pointing it out -- not sure how that happened to begin with. Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Steve Ebersole" To: "Guillaume Smet" Cc: "Hibernate" Sent: Sunday, March 9, 2014 12:20:42 PM Subject: Re: [hibernate-dev] Code templates empty on "Contributing to Hibernate using Eclipse" page Yes, it should. Could someone that actually works with Eclipse fix that? Sanne you seem to be the only one updating this page; could you maybe upload yours? Or Brett, I know you use Eclipse off/on, could you? On Fri, Mar 7, 2014 at 9:02 AM, Guillaume Smet wrote: > Hi, > > I already mentioned it here a while ago: the code-templates.xml file > at the bottom of > https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse > is empty. > > IIRC, it should at least contain the Copyright header? > > Thanks! > > -- > Guillaume > _______________________________________________ > 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 emmanuel at hibernate.org Mon Mar 10 13:13:12 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 10 Mar 2014 17:13:12 +0000 Subject: [hibernate-dev] How to publish the website Message-ID: <20140310171312.GP31430@hibernate.org> I finally resolve WEBSITE-95 and explained how to build the website. It is on the survival guide web page which is reachable from http://hibernate.org/README/. http://hibernate.org/survival-guide/#publishing-the-site Emmanuel From hardy at hibernate.org Mon Mar 10 14:25:15 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 10 Mar 2014 19:25:15 +0100 Subject: [hibernate-dev] How to publish the website In-Reply-To: <20140310171312.GP31430@hibernate.org> References: <20140310171312.GP31430@hibernate.org> Message-ID: <1D368D5F-D84D-4F93-B7A5-CE4A3659D873@hibernate.org> Nice On 10 Jan 2014, at 18:13, Emmanuel Bernard wrote: > I finally resolve WEBSITE-95 and explained how to build the website. > It is on the survival guide web page which is reachable from > http://hibernate.org/README/. > > http://hibernate.org/survival-guide/#publishing-the-site > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Mar 11 03:41:53 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 11 Mar 2014 08:41:53 +0100 Subject: [hibernate-dev] Code templates empty on "Contributing to Hibernate using Eclipse" page In-Reply-To: <235386318.24186313.1394465166548.JavaMail.zimbra@redhat.com> References: <235386318.24186313.1394465166548.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Mar 10, 2014 at 4:26 PM, Brett Meyer wrote: > Done! Thanks for pointing it out -- not sure how that happened to begin with. Thanks, Brett. -- Guillaume From hardy at hibernate.org Tue Mar 11 06:37:43 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 11 Mar 2014 11:37:43 +0100 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: <532310CD-FC38-4FE6-96DB-793338D47CD3@hibernate.org> On 9 Jan 2014, at 18:31, Steve Ebersole wrote: > Then we had expanded the previous discussion to look at the more general > case... interface based models. Imo, the best way to map the above model > would be: > > @Entity > interface Employee { > ... > } > > Yes, this deviates from JPA which explicitly says that only classes can be > annotated. The question is whether we think its worthy of a "vendor > extension?. Not sure whether I am a big fan of this. As a first gut feeling I would give it a -1 From emmanuel at hibernate.org Tue Mar 11 06:51:03 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 11 Mar 2014 10:51:03 +0000 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: References: Message-ID: <20140311105103.GQ31430@hibernate.org> That would be extremely useful. That being said, it's not the only useful context. On top of the "entity" context, I can see usage for: - per event context (flush event for example) - transaction context - global session context (not sure I have a use case yet but I suspect it's useful. Emmanuel On Mon 2014-03-10 15:24, Sanne Grinovero wrote: > This seems like related to the relation-walking optimization we > discussed for Neo4J: also would need to couple the entity instance to > the Neo4J document. Currently the Neo4J griddialect would need to run > a new query for a graph-traversal: not taking advantage of the graph > capabilities which is of course a problem. > > In Hibernate ORM the EntityEntry stores an array with the loaded > values from SQL, needed for some of its state handling. I'd say we > should have a way to store data related to extension points into this > EntityEntry. > > If we made this as a general purpose enhancement of ORM, we could > maybe have it abstract the storage of the additional attributes into, > for example, the enhanced entity class definitions: it would add a > field directly to the Entity instance for you to store such an object. > There where some chats about maybe doing such an optimization anyway, > driven by the performance work. > > Sanne > > On 10 March 2014 12:32, Gunnar Morling wrote: > > Minor correction: > > > >> Unfortunately there is no getter for the session owner on > > SessionFactoryImplementor > > > > s/SessionFactoryImplementor/SessionImplementor > > > > --Gunnar > > > > > > > > > > 2014-03-10 12:59 GMT+01:00 Gunnar Morling : > > > >> Hi, > >> > >> I'm looking into ways for reducing the number of datastore roundtrips in > >> OGM [1]. > >> > >> One idea is to fetch associations embedded within entity documents (e.g. > >> in MongoDB) when loading such document. We'd "remember" the entity document > >> and could later on retrieve the association from it without going to the > >> store a second time. > >> > >> The problem is the "remembering" part. There is no session-scoped storage > >> facility as of today which I could use. I contemplated making OgmSession > >> deal with this, but I can't access that from persisters etc. Instead I'm > >> seeing the wrapped SessionImpl (to which OgmSession delegates for many > >> operations) and I couldn't find a way to reach the wrapping OgmSession > >> instance. > >> > >> Now I noticed the concept of "SessionOwner" in SessionImpl and am > >> wondering whether I could make use of this. When creating the SessionImpl, > >> I could pass the OgmSession as owner and have it maintain a session-scoped > >> storage. Unfortunately there is no getter for the session owner on > >> SessionFactoryImplementor, though. > >> > >> Would it be feasible to add this getter and thus make a session's owner > >> accessible? Or is there any other (better) way to achieve what I described? > >> > >> Many thanks, > >> > >> --Gunnar > >> > >> [1] https://hibernate.atlassian.net/browse/OGM-469 > >> > >> > > _______________________________________________ > > 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 emmanuel at hibernate.org Tue Mar 11 06:58:20 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 11 Mar 2014 10:58:20 +0000 Subject: [hibernate-dev] How to publish the website In-Reply-To: <1D368D5F-D84D-4F93-B7A5-CE4A3659D873@hibernate.org> References: <20140310171312.GP31430@hibernate.org> <1D368D5F-D84D-4F93-B7A5-CE4A3659D873@hibernate.org> Message-ID: <20140311105820.GR31430@hibernate.org> BTW it is minimalist atm, but if you ask questions here, I'll update that section. Emmanuel On Mon 2014-03-10 19:25, Hardy Ferentschik wrote: > Nice > > On 10 Jan 2014, at 18:13, Emmanuel Bernard wrote: > > > I finally resolve WEBSITE-95 and explained how to build the website. > > It is on the survival guide web page which is reachable from > > http://hibernate.org/README/. > > > > http://hibernate.org/survival-guide/#publishing-the-site > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Tue Mar 11 06:59:29 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 11 Mar 2014 11:59:29 +0100 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: 2014-03-09 18:31 GMT+01:00 Steve Ebersole : @Entity > interface Employee { > ... > } > > 2) We'd dynamically generate a class to back this. This generated class > can contain many of the performance tweaks we've been developing via > bytecode extensions (inline dirty-checking, "entity entry" info, etc). > In which situation would one make use of this? This seems to encourage "anemic data models", i.e. entities which are just data holders but don't contain any business logic. Often it's very useful though to add logic dealing with an entity's state to the entity type itself. Will the class be generated at build or runtime? In case of the latter, how would one instantiate such entity? On a somewhat related note, I've been contemplating the notion of "partially mapped entities" in OGM [1]. Those would provide explicit properties only for some attributes (common ones, or ones which business logic relates to), while others would be exposed via a generic map structure: @Entity public class Product { @Id private long id; private String name; private BigDecimal price; @AdditionalProperties private Map additionalProperties; // ... } This would be very beneficial for NoSQL use cases where you want to pass through data from the store to a GUI in a generic manner or during prototyping/rapid development, where you manifest more and more attributes as explicit properties, just as business logic requires it. --Gunnar [1] https://hibernate.atlassian.net/browse/OGM-470 _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Mar 11 11:24:18 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Mar 2014 10:24:18 -0500 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: <532310CD-FC38-4FE6-96DB-793338D47CD3@hibernate.org> References: <532310CD-FC38-4FE6-96DB-793338D47CD3@hibernate.org> Message-ID: But you're OK with the following instead? @Entity @Proxy(proxyClass=Employee.class) class EmployeeImpl implements Employee { ... } ? See I find that (^^) less clear and less concise. What's the basis for your gut to say -1? Because it "breaks" from JPA? On Tue, Mar 11, 2014 at 5:37 AM, Hardy Ferentschik wrote: > > On 9 Jan 2014, at 18:31, Steve Ebersole wrote: > > > Then we had expanded the previous discussion to look at the more general > > case... interface based models. Imo, the best way to map the above model > > would be: > > > > @Entity > > interface Employee { > > ... > > } > > > > Yes, this deviates from JPA which explicitly says that only classes can > be > > annotated. The question is whether we think its worthy of a "vendor > > extension". > > Not sure whether I am a big fan of this. As a first gut feeling I would > give it a -1 > > From steve at hibernate.org Tue Mar 11 11:44:07 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Mar 2014 10:44:07 -0500 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: References: Message-ID: I'm OK with exposing a getSessionOwner() method. This could actually be helpful in other places like envers iiuc. On Mon, Mar 10, 2014 at 6:59 AM, Gunnar Morling wrote: > Hi, > > I'm looking into ways for reducing the number of datastore roundtrips in > OGM [1]. > > One idea is to fetch associations embedded within entity documents (e.g. in > MongoDB) when loading such document. We'd "remember" the entity document > and could later on retrieve the association from it without going to the > store a second time. > > The problem is the "remembering" part. There is no session-scoped storage > facility as of today which I could use. I contemplated making OgmSession > deal with this, but I can't access that from persisters etc. Instead I'm > seeing the wrapped SessionImpl (to which OgmSession delegates for many > operations) and I couldn't find a way to reach the wrapping OgmSession > instance. > > Now I noticed the concept of "SessionOwner" in SessionImpl and am wondering > whether I could make use of this. When creating the SessionImpl, I could > pass the OgmSession as owner and have it maintain a session-scoped storage. > Unfortunately there is no getter for the session owner on > SessionFactoryImplementor, though. > > Would it be feasible to add this getter and thus make a session's owner > accessible? Or is there any other (better) way to achieve what I described? > > Many thanks, > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/OGM-469 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Mar 11 11:46:54 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Mar 2014 10:46:54 -0500 Subject: [hibernate-dev] Storing values at the session level In-Reply-To: <32809A12-195B-49B9-B3C5-ACAA4A477034@hibernate.org> References: <32809A12-195B-49B9-B3C5-ACAA4A477034@hibernate.org> Message-ID: On Mon, Mar 10, 2014 at 7:29 AM, Emmanuel Bernard wrote: > Either this or have on the session owner contract a generic facility to > store session specific data that OGM could extend. > I think Steve has been reluctant of such contract in the past. We could re > discuss the pluses and minuses. > > Another alternative is to use transactions as the payload transport. But > the synchronization concept does not let you lookup for data outside the > before and after tx events. > For years, JBoss had a TransactionLocal class. Modeled on the JDK ThreadLocal class. Sounds like that's maybe what you are describing? Not saying its right or wrong way to achieve what you suggest, just pointing out that your concerns about data access have been addressed before elsewhere. From sanne at hibernate.org Tue Mar 11 12:45:19 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 11 Mar 2014 16:45:19 +0000 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: On 11 March 2014 10:59, Gunnar Morling wrote: > 2014-03-09 18:31 GMT+01:00 Steve Ebersole : > > @Entity >> interface Employee { >> ... >> } >> >> 2) We'd dynamically generate a class to back this. This generated class >> can contain many of the performance tweaks we've been developing via >> bytecode extensions (inline dirty-checking, "entity entry" info, etc). >> > > In which situation would one make use of this? This seems to encourage > "anemic data models", i.e. entities which are just data holders but don't > contain any business logic. Often it's very useful though to add logic > dealing with an entity's state to the entity type itself. I actually see this going in the opposite direction. Allowing to move all the mapping stuff to a different interface would encourage me to think of the implementation as something which can include code, and I could even have multiple types having different *implementations* if the non-persistent methods. It would also fight usage of inheritance, which is common among JPA users and something that I'd gladly avoid. Would be a very nice to have to avoid anemic data models. > > Will the class be generated at build or runtime? In case of the latter, how > would one instantiate such entity? > > On a somewhat related note, I've been contemplating the notion of > "partially mapped entities" in OGM [1]. Those would provide explicit > properties only for some attributes (common ones, or ones which business > logic relates to), while others would be exposed via a generic map > structure: > > @Entity > public class Product { > > @Id > private long id; > private String name; > private BigDecimal price; > > @AdditionalProperties > private Map additionalProperties; > > // ... > } > > This would be very beneficial for NoSQL use cases where you want to pass > through data from the store to a GUI in a generic manner or during > prototyping/rapid development, where you manifest more and more attributes > as explicit properties, just as business logic requires it. > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/OGM-470 > > _______________________________________________ >> 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 Mar 11 13:08:11 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 11 Mar 2014 18:08:11 +0100 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: 2014-03-11 17:45 GMT+01:00 Sanne Grinovero : > On 11 March 2014 10:59, Gunnar Morling wrote: > > 2014-03-09 18:31 GMT+01:00 Steve Ebersole : > > > > @Entity > >> interface Employee { > >> ... > >> } > >> > >> 2) We'd dynamically generate a class to back this. This generated class > >> can contain many of the performance tweaks we've been developing via > >> bytecode extensions (inline dirty-checking, "entity entry" info, etc). > >> > > > > In which situation would one make use of this? This seems to encourage > > "anemic data models", i.e. entities which are just data holders but don't > > contain any business logic. Often it's very useful though to add logic > > dealing with an entity's state to the entity type itself. > > I actually see this going in the opposite direction. Allowing to move > all the mapping stuff to a different interface would encourage me to > think of the implementation as something which can include code, and I > could even have multiple types having different *implementations* if > the non-persistent methods. > > It would also fight usage of inheritance, which is common among JPA > users and something that I'd gladly avoid. > > Would be a very nice to have to avoid anemic data models. > I'm not following. The idea in 2) (which I was referring to) was to *generate* the implementation class. How does a custom implementation play into this? Are you referring to alternative 1) maybe? > > > > > Will the class be generated at build or runtime? In case of the latter, > how > > would one instantiate such entity? > > > > On a somewhat related note, I've been contemplating the notion of > > "partially mapped entities" in OGM [1]. Those would provide explicit > > properties only for some attributes (common ones, or ones which business > > logic relates to), while others would be exposed via a generic map > > structure: > > > > @Entity > > public class Product { > > > > @Id > > private long id; > > private String name; > > private BigDecimal price; > > > > @AdditionalProperties > > private Map additionalProperties; > > > > // ... > > } > > > > This would be very beneficial for NoSQL use cases where you want to pass > > through data from the store to a GUI in a generic manner or during > > prototyping/rapid development, where you manifest more and more > attributes > > as explicit properties, just as business logic requires it. > > > > --Gunnar > > > > [1] https://hibernate.atlassian.net/browse/OGM-470 > > > > _______________________________________________ > >> 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 Tue Mar 11 13:17:09 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 11 Mar 2014 17:17:09 +0000 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: On 11 March 2014 17:08, Gunnar Morling wrote: > > > > 2014-03-11 17:45 GMT+01:00 Sanne Grinovero : > >> On 11 March 2014 10:59, Gunnar Morling wrote: >> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole : >> > >> > @Entity >> >> interface Employee { >> >> ... >> >> } >> >> >> >> 2) We'd dynamically generate a class to back this. This generated >> >> class >> >> can contain many of the performance tweaks we've been developing via >> >> bytecode extensions (inline dirty-checking, "entity entry" info, etc). >> >> >> > >> > In which situation would one make use of this? This seems to encourage >> > "anemic data models", i.e. entities which are just data holders but >> > don't >> > contain any business logic. Often it's very useful though to add logic >> > dealing with an entity's state to the entity type itself. >> >> I actually see this going in the opposite direction. Allowing to move >> all the mapping stuff to a different interface would encourage me to >> think of the implementation as something which can include code, and I >> could even have multiple types having different *implementations* if >> the non-persistent methods. >> >> It would also fight usage of inheritance, which is common among JPA >> users and something that I'd gladly avoid. >> >> Would be a very nice to have to avoid anemic data models. > > > I'm not following. The idea in 2) (which I was referring to) was to > *generate* the implementation class. How does a custom implementation play > into this? Are you referring to alternative 1) maybe? Sorry I forgot to qualify. I thought it would be nice to have both, and 2) would the the fallback approach in case no implementation is available. That would allow the "persistence team" (yes in some places they have dedicated teams) be able to create the model as an interface, play and test with it, and then another team actually provides an useful implementation. In the scope of the persistence testing, you're fine with the anemic model. Sanne From steve at hibernate.org Tue Mar 11 13:49:56 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Mar 2014 12:49:56 -0500 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: There are actually lots of great use cases for pure persistence models. Prototyping, modeling, designing is one as Sanne mentioned. "Dynamic" models is another. You see this is envers, grails, and other places. Also, whether *you* think persistence models should or should not be anemic is fine. That's your choice. Not everyone in the world needs to agree with you ;) On Tue, Mar 11, 2014 at 12:17 PM, Sanne Grinovero wrote: > On 11 March 2014 17:08, Gunnar Morling wrote: > > > > > > > > 2014-03-11 17:45 GMT+01:00 Sanne Grinovero : > > > >> On 11 March 2014 10:59, Gunnar Morling wrote: > >> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole : > >> > > >> > @Entity > >> >> interface Employee { > >> >> ... > >> >> } > >> >> > >> >> 2) We'd dynamically generate a class to back this. This generated > >> >> class > >> >> can contain many of the performance tweaks we've been developing via > >> >> bytecode extensions (inline dirty-checking, "entity entry" info, > etc). > >> >> > >> > > >> > In which situation would one make use of this? This seems to encourage > >> > "anemic data models", i.e. entities which are just data holders but > >> > don't > >> > contain any business logic. Often it's very useful though to add logic > >> > dealing with an entity's state to the entity type itself. > >> > >> I actually see this going in the opposite direction. Allowing to move > >> all the mapping stuff to a different interface would encourage me to > >> think of the implementation as something which can include code, and I > >> could even have multiple types having different *implementations* if > >> the non-persistent methods. > >> > >> It would also fight usage of inheritance, which is common among JPA > >> users and something that I'd gladly avoid. > >> > >> Would be a very nice to have to avoid anemic data models. > > > > > > I'm not following. The idea in 2) (which I was referring to) was to > > *generate* the implementation class. How does a custom implementation > play > > into this? Are you referring to alternative 1) maybe? > > Sorry I forgot to qualify. I thought it would be nice to have both, > and 2) would the the fallback approach in case no implementation is > available. > > That would allow the "persistence team" (yes in some places they have > dedicated teams) be able to create the model as an interface, play and > test with it, and then another team actually provides an useful > implementation. > > In the scope of the persistence testing, you're fine with the anemic model. > > Sanne > From steve at hibernate.org Tue Mar 11 13:52:53 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Mar 2014 12:52:53 -0500 Subject: [hibernate-dev] IRC Developer meeting - 3/11 Message-ID: Mainly we discussed OGM and its evolving need for contextual info and how to best make that accessible from ORM contracts such as Session. Also, I gave an update on the Jira/GitHub email from last week. [12:46] Meeting ended Tue Mar 11 17:34:51 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [12:46] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.html [12:46] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.txt [12:46] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html From gunnar at hibernate.org Tue Mar 11 13:58:14 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 11 Mar 2014 18:58:14 +0100 Subject: [hibernate-dev] Possibly interesting use of Jandex In-Reply-To: References: Message-ID: 2014-03-11 18:17 GMT+01:00 Sanne Grinovero : > On 11 March 2014 17:08, Gunnar Morling wrote: > > > > > > > > 2014-03-11 17:45 GMT+01:00 Sanne Grinovero : > > > >> On 11 March 2014 10:59, Gunnar Morling wrote: > >> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole : > >> > > >> > @Entity > >> >> interface Employee { > >> >> ... > >> >> } > >> >> > >> >> 2) We'd dynamically generate a class to back this. This generated > >> >> class > >> >> can contain many of the performance tweaks we've been developing via > >> >> bytecode extensions (inline dirty-checking, "entity entry" info, > etc). > >> >> > >> > > >> > In which situation would one make use of this? This seems to encourage > >> > "anemic data models", i.e. entities which are just data holders but > >> > don't > >> > contain any business logic. Often it's very useful though to add logic > >> > dealing with an entity's state to the entity type itself. > >> > >> I actually see this going in the opposite direction. Allowing to move > >> all the mapping stuff to a different interface would encourage me to > >> think of the implementation as something which can include code, and I > >> could even have multiple types having different *implementations* if > >> the non-persistent methods. > >> > >> It would also fight usage of inheritance, which is common among JPA > >> users and something that I'd gladly avoid. > >> > >> Would be a very nice to have to avoid anemic data models. > > > > > > I'm not following. The idea in 2) (which I was referring to) was to > > *generate* the implementation class. How does a custom implementation > play > > into this? Are you referring to alternative 1) maybe? > > Sorry I forgot to qualify. I thought it would be nice to have both, > and 2) would the the fallback approach in case no implementation is > available. > > That would allow the "persistence team" (yes in some places they have > dedicated teams) be able to create the model as an interface, play and > test with it, and then another team actually provides an useful > implementation. > > In the scope of the persistence testing, you're fine with the anemic model. > Yes, 1) seems useful in some cases. Regarding an impl fully generated (2), my question still is how users would construct instances. Would there be a factory method? Also how would equality be defined? > > Sanne > From gunnar at hibernate.org Wed Mar 12 06:21:06 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 12 Mar 2014 11:21:06 +0100 Subject: [hibernate-dev] [OGM] Element collections stored embedded in entity Message-ID: Hi, I just did some testing around @ElementCollection using MongoDB. A collection of a basic type results in the following persistent format of the embedding entity: { "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", "nicknames": [ { "nicknames": "idrA" }, { "nicknames": "day[9]" } ] } Is there any reason why we don't use this instead: { "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", "nicknames": [ "idrA", "day[9]" ] } For non-basic, embeddable types it looks like this: { "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", "homeAddress": [ { "homeAddress.collection&&element.city": "Paris", "homeAddress.collection&&element.country": "France", "homeAddress.collection&&element.street1": "1 avenue des Champs Elysees", "homeAddress.collection&&element.street2": null, "postal_code": "75007" } ] } Is this "collection&&element" style intended, or could we use the simple property name as keys here ("postal_code" is specified explicitly via @Column)? I can file issues in JIRA (and take a look at some point), but wanted to be sure I'm not missing something here. Thanks, --Gunnar From emmanuel at hibernate.org Wed Mar 12 09:48:51 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 12 Mar 2014 13:48:51 +0000 Subject: [hibernate-dev] [OGM] Element collections stored embedded in entity In-Reply-To: References: Message-ID: <2283DDD7-328B-4F91-AF85-F1D063D62608@hibernate.org> There are two problems, I am not sure why it uses "nicknames" as the property name, I don't think that's the actual default value in JPA, is it? Otherwise, I agree with you, we could simplify it except when the collection is keyed or indexed. At this stage you need to store the key or the index next to the value. About collection&&element, the bug is already opened https://hibernate.atlassian.net/browse/OGM-251 Hasn't been addressed yet :( Emmanuel On 12 Mar 2014, at 10:21, Gunnar Morling wrote: > Hi, > > I just did some testing around @ElementCollection using MongoDB. A > collection of a basic type results in the following persistent format > of > the embedding entity: > > { > "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", > "nicknames": [ > { "nicknames": "idrA" }, > { "nicknames": "day[9]" } > ] > } > > Is there any reason why we don't use this instead: > > { > "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", > "nicknames": [ > "idrA", > "day[9]" > ] > } > > For non-basic, embeddable types it looks like this: > > { > "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", > "homeAddress": [ > { > "homeAddress.collection&&element.city": "Paris", > "homeAddress.collection&&element.country": "France", > "homeAddress.collection&&element.street1": "1 avenue des > Champs Elysees", > "homeAddress.collection&&element.street2": null, > "postal_code": "75007" > } > ] > } > > Is this "collection&&element" style intended, or could we use the > simple > property name as keys here ("postal_code" is specified explicitly via > @Column)? > > I can file issues in JIRA (and take a look at some point), but wanted > to be > sure I'm not missing something here. > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Mar 12 09:57:04 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 12 Mar 2014 14:57:04 +0100 Subject: [hibernate-dev] [OGM] Element collections stored embedded in entity In-Reply-To: <2283DDD7-328B-4F91-AF85-F1D063D62608@hibernate.org> References: <2283DDD7-328B-4F91-AF85-F1D063D62608@hibernate.org> Message-ID: 2014-03-12 14:48 GMT+01:00 Emmanuel Bernard : > There are two problems, > > I am not sure why it uses "nicknames" as the property name, I don't think > that's the actual default value in JPA, is it? > Default value in which way? > Otherwise, I agree with you, we could simplify it except when the > collection is keyed or indexed. At this stage you need to store the key or > the index next to the value. > Yes, sure. This is about a simple non-ordered collection (a Set in this case). > > About collection&&element, the bug is already opened > https://hibernate.atlassian.net/browse/OGM-251 > Hasn't been addressed yet :( > Ah, never noticed that one before. Just assigned it to me. --Gunnar > > Emmanuel > > > On 12 Mar 2014, at 10:21, Gunnar Morling wrote: > > Hi, >> >> I just did some testing around @ElementCollection using MongoDB. A >> collection of a basic type results in the following persistent format of >> the embedding entity: >> >> { >> "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", >> "nicknames": [ >> { "nicknames": "idrA" }, >> { "nicknames": "day[9]" } >> ] >> } >> >> Is there any reason why we don't use this instead: >> >> { >> "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", >> "nicknames": [ >> "idrA", >> "day[9]" >> ] >> } >> >> For non-basic, embeddable types it looks like this: >> >> { >> "_id": "17457a47-abfc-4fb7-955e-17acb0b49808", >> "homeAddress": [ >> { >> "homeAddress.collection&&element.city": "Paris", >> "homeAddress.collection&&element.country": "France", >> "homeAddress.collection&&element.street1": "1 avenue des >> Champs Elysees", >> "homeAddress.collection&&element.street2": null, >> "postal_code": "75007" >> } >> ] >> } >> >> Is this "collection&&element" style intended, or could we use the simple >> property name as keys here ("postal_code" is specified explicitly via >> @Column)? >> >> I can file issues in JIRA (and take a look at some point), but wanted to >> be >> sure I'm not missing something here. >> >> Thanks, >> >> --Gunnar >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Sat Mar 15 13:48:21 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 15 Mar 2014 12:48:21 -0500 Subject: [hibernate-dev] @ManyToOne + @Basic Message-ID: There is a test currently failing with the new metamodel code. The mapping that causes the problem has the following annotations: @Id @ManyToOne(...) @JoinColumns(...) @Basic(fetch=FetchType.LAZY) Is it really legal to combine @ManyToOne and @Basic? Those seem "at odds". My guess is that the legacy binding code simply did not validate for this. Wdyt? From sanne at hibernate.org Sun Mar 16 17:07:23 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 16 Mar 2014 21:07:23 +0000 Subject: [hibernate-dev] Permissions and teams update; teaser on the Docker work Message-ID: I've created a new team for the Hibernate HQL parser project, as there is some overlap with other projects beyond the Hibernate OGM team. Then added - Adrian Nistor to the Hibernate organization (to the parser project) - Everyone who was on OGM to the parser project - Steve Ebersole to the parser project - Paolo Antinori to the Hibernate organization (devops project) Paolo is working on a Docker based testsuite for Hibernate OGM, and I hope to reuse some of that for relational databases too. I'll let him describe his work better when it's ready. An article on these early experiments made it to DZone: http://www.dzone.com/links/r/integration_testing_with_maven_and_docker.html -- Sanne From emmanuel at hibernate.org Mon Mar 17 10:29:06 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 17 Mar 2014 15:29:06 +0100 Subject: [hibernate-dev] Hakergarten session for Devoxx France Message-ID: <20140317142906.GA41331@hibernate.org> I will be at Devoxx France to help on a Hackergarten session. This is basically some time where people come to contribute to a project, hopefully being the start of a long relationship :) I can mentor people around Hibernate Search and Hibernate OGM. Could you tag some issues on JIRA as easily doable in 1 to 2 hours. Emmanuel From sanne at hibernate.org Mon Mar 17 11:09:04 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 17 Mar 2014 15:09:04 +0000 Subject: [hibernate-dev] Hakergarten session for Devoxx France In-Reply-To: <20140317142906.GA41331@hibernate.org> References: <20140317142906.GA41331@hibernate.org> Message-ID: I've used the "hackergarten" label for Search. Essentially I've picked among the ones already tagged as "suited for new contributors" those which I think are doable in shortest time. https://hibernate.atlassian.net/issues/?jql=labels%20%3D%20hackergarten Davide could you use the same label for OGM? Sanne On 17 March 2014 14:29, Emmanuel Bernard wrote: > I will be at Devoxx France to help on a Hackergarten session. This is > basically some time where people come to contribute to a project, > hopefully being the start of a long relationship :) > > I can mentor people around Hibernate Search and Hibernate OGM. Could you > tag some issues on JIRA as easily doable in 1 to 2 hours. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Mon Mar 17 11:52:11 2014 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 17 Mar 2014 15:52:11 +0000 Subject: [hibernate-dev] Hakergarten session for Devoxx France In-Reply-To: References: <20140317142906.GA41331@hibernate.org> Message-ID: I've used the same label On Mon, Mar 17, 2014 at 3:09 PM, Sanne Grinovero wrote: > I've used the "hackergarten" label for Search. > Essentially I've picked among the ones already tagged as "suited for > new contributors" those which I think are doable in shortest time. > > https://hibernate.atlassian.net/issues/?jql=labels%20%3D%20hackergarten > > Davide could you use the same label for OGM? > > Sanne > > On 17 March 2014 14:29, Emmanuel Bernard wrote: > > I will be at Devoxx France to help on a Hackergarten session. This is > > basically some time where people come to contribute to a project, > > hopefully being the start of a long relationship :) > > > > I can mentor people around Hibernate Search and Hibernate OGM. Could you > > tag some issues on JIRA as easily doable in 1 to 2 hours. > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Mon Mar 17 12:42:02 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 17 Mar 2014 17:42:02 +0100 Subject: [hibernate-dev] Hakergarten session for Devoxx France In-Reply-To: References: <20140317142906.GA41331@hibernate.org> Message-ID: <3401EDEC-FD72-428B-BC07-EA574221C84C@hibernate.org> Thanks guys. On 17 Mar 2014, at 16:52, Davide D'Alto wrote: > I've used the same label > > > On Mon, Mar 17, 2014 at 3:09 PM, Sanne Grinovero wrote: > >> I've used the "hackergarten" label for Search. >> Essentially I've picked among the ones already tagged as "suited for >> new contributors" those which I think are doable in shortest time. >> >> https://hibernate.atlassian.net/issues/?jql=labels%20%3D%20hackergarten >> >> Davide could you use the same label for OGM? >> >> Sanne >> >> On 17 March 2014 14:29, Emmanuel Bernard wrote: >>> I will be at Devoxx France to help on a Hackergarten session. This is >>> basically some time where people come to contribute to a project, >>> hopefully being the start of a long relationship :) >>> >>> I can mentor people around Hibernate Search and Hibernate OGM. Could you >>> tag some issues on JIRA as easily doable in 1 to 2 hours. >>> >>> Emmanuel >>> _______________________________________________ >>> 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 brmeyer at redhat.com Mon Mar 17 12:45:15 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 17 Mar 2014 12:45:15 -0400 (EDT) Subject: [hibernate-dev] @ManyToOne + @Basic In-Reply-To: References: Message-ID: <622623588.800174.1395074715230.JavaMail.zimbra@redhat.com> +1 -- I don't think that should be valid. Conceptually, it makes no sense. I'm wondering if that came from a contributor that was simply trying to make it LAZY, but didn't understand how to properly do that with annotations... Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Steve Ebersole" To: "hibernate-dev" Sent: Saturday, March 15, 2014 1:48:21 PM Subject: [hibernate-dev] @ManyToOne + @Basic There is a test currently failing with the new metamodel code. The mapping that causes the problem has the following annotations: @Id @ManyToOne(...) @JoinColumns(...) @Basic(fetch=FetchType.LAZY) Is it really legal to combine @ManyToOne and @Basic? Those seem "at odds". My guess is that the legacy binding code simply did not validate for this. Wdyt? _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Mon Mar 17 12:56:13 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 17 Mar 2014 17:56:13 +0100 Subject: [hibernate-dev] @ManyToOne + @Basic In-Reply-To: References: Message-ID: <6A9DA151-9C98-4293-A92F-50AC770E58D0@hibernate.org> Yes that looks fishy. The only explanation I can see is if that approach is supposed to use the byte code enhancement lazy as opposed to proxy but AFAIR we have different annotations to express that. On 15 Mar 2014, at 18:48, Steve Ebersole wrote: > There is a test currently failing with the new metamodel code. The mapping > that causes the problem has the following annotations: > > @Id > @ManyToOne(...) > @JoinColumns(...) > @Basic(fetch=FetchType.LAZY) > > Is it really legal to combine @ManyToOne and @Basic? Those seem "at odds". > My guess is that the legacy binding code simply did not validate for this. > > Wdyt? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Mar 17 17:10:54 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 17 Mar 2014 21:10:54 +0000 Subject: [hibernate-dev] ci.hibernate.org and network port assignment Message-ID: I've created WEBSITE-178 [1] as once again we had testsuites failing because of a network port being used by a different job; bad luck, but we can do better. Assuming we want to use the Jenkins plugin "port allocator", this would however need to be consistently honored by all builds we launch: it passes variables which we should use, but it can't enforce them AFAIK. Is that going to be maintanable in the long run? An alternative would be to consistently run each and every build in its own isolated docker container, but a) that's not something I can setup overnight b) we'd need to use more complex build scripts, for example the nice Maven and Gradle integrations with the Jenkins build configuration would be unusable. We're having quite a list of services; even ignoring the OGM exotic databases we have at least: - Byteman - JGroups - Arquillian - WildFly - ActiveMQ (JMS tests in Search) - ... ? To fight the urgent need, I'm going to prevent parallelism of any build. Let's hope ORM's master doesn't get stuck, as everything else would be blocked. I really hope this measure stays as temporary as possible :-/ -- Sanne 1 - https://hibernate.atlassian.net/browse/WEBSITE-178 2 - https://wiki.jenkins-ci.org/display/JENKINS/Port+Allocator+Plugin From brmeyer at redhat.com Mon Mar 17 17:55:14 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 17 Mar 2014 17:55:14 -0400 (EDT) Subject: [hibernate-dev] Hibernate ORM 4.2.11.Final released Message-ID: <1007575339.1102539.1395093314628.JavaMail.zimbra@redhat.com> http://in.relation.to/Bloggers/HibernateORM4211FinalReleased Brett Meyer Red Hat, Hibernate ORM From steve at hibernate.org Tue Mar 18 13:06:41 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 18 Mar 2014 12:06:41 -0500 Subject: [hibernate-dev] IRC Developer meeting - 3/18 Message-ID: Discussed forums and metamodel (5.0) development [12:05] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-18-15.48.html [12:05] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-18-15.48.txt [12:05] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-18-15.48.log.html From guillaume.smet at gmail.com Tue Mar 18 13:26:50 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 18 Mar 2014 18:26:50 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> Message-ID: Hi, On Tue, Mar 4, 2014 at 7:06 PM, Guillaume Smet wrote: > I'll post as soon as I have a working prototype of what I would like > to achieve and then we can discuss from there. I finally succeeded in committing a few hours to prototype what I have in mind: https://github.com/openwide-java/hibernate-search/commits/prototype-plain-text-search It's a very simple patch. I added a test case to the DSLTest. It's a work in progress but I think it might be easier to understand what I have in mind once you have taken a look at this. I needed the SimpleQueryParser of Lucene 4.7 so I included it: it's a vanilla version so we can remove it after the move to 4.7. What I would like to do: - add the ability to indicate that you want a fuzzy search for a given field in the DSL - I don't like the withAllTerms() option. I would like this behavior to be the default and to have something like "defaultOperatorIsOr()": it defines the default operator when you don't use an explicit one. I'm not sure defaultOperatorIsOr() is something acceptable/understandable. Where I would like advice/opinion: - does it look like a good idea or something horrible? - I'm still hesitant about what to do with field bridges: atm, I don't take them into account at all - I think having a DSL branch for text search is necessary even if it might seem very similar to term search Comments welcome. -- Guillaume From paolo.antinori at gmail.com Tue Mar 18 18:49:43 2014 From: paolo.antinori at gmail.com (Paolo Antinori) Date: Tue, 18 Mar 2014 22:49:43 +0000 Subject: [hibernate-dev] ci.hibernate.org and network port assignment Message-ID: hi everyone, I'll be happy to help with the activity of isolating build job in docker containers started directly via jenkins. The technology should allow concurrent build job totally isolated, as anticipated. I am going to start with OGM that is the project I am more familiar with and I will let you know of eventual achievement. paolo I've created WEBSITE-178 [1] as once again we had testsuites failing because of a network port being used by a different job; bad luck, but we can do better. Assuming we want to use the Jenkins plugin "port allocator", this would however need to be consistently honored by all builds we launch: it passes variables which we should use, but it can't enforce them AFAIK. Is that going to be maintanable in the long run? An alternative would be to consistently run each and every build in its own isolated docker container, but a) that's not something I can setup overnight b) we'd need to use more complex build scripts, for example the nice Maven and Gradle integrations with the Jenkins build configuration would be unusable. We're having quite a list of services; even ignoring the OGM exotic databases we have at least: - Byteman - JGroups - Arquillian - WildFly - ActiveMQ (JMS tests in Search) - ... ? To fight the urgent need, I'm going to prevent parallelism of any build. Let's hope ORM's master doesn't get stuck, as everything else would be blocked. I really hope this measure stays as temporary as possible :-/ -- Sanne From guillaume.smet at hibernate.org Wed Mar 19 06:55:29 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 19 Mar 2014 11:55:29 +0100 Subject: [hibernate-dev] DefaultLoadEventListener and second level cache Message-ID: Hi, We have a lot of second level cache misses on one of our applications and I wanted to understand why it was the case. These cache misses happen even after loading twice the exact same page. They are coming from entities which are loaded via DefaultLoadEventListener. I tried to debug it and was looking for the place where the entity is put in the cache when the DefaultLoadEventListener path is used. Could someone point me to where we put the entity in the cache so that I can try debugging further? Thanks in advance. -- Guillaume From guillaume.smet at hibernate.org Wed Mar 19 07:10:17 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 19 Mar 2014 12:10:17 +0100 Subject: [hibernate-dev] Make HibernatePersistenceProvider easier to extend In-Reply-To: References: Message-ID: Hi, Any thoughts on this one? I have bandwidth this week if it's considered something we want. Thanks. On Thu, Jan 23, 2014 at 2:08 PM, Guillaume Smet wrote: > Hi, > > I'm starting our migration to ORM 4.3 to be able to provide some > (hopefully useful) feedback on ORM 4.3 and Search 4.5. > > One thing we did in most of our apps was injecting Spring managed > interceptor into the session factory using a trick very similar to > what is explained there: > http://blog.krecan.net/2009/01/24/spring-managed-hibernate-interceptor-in-jpa/. > > This (kinda ugly) trick doesn't work any more in 4.3 and I ended up > doing the following: > https://gist.github.com/gsmet/8578138 > which works but is IMHO very fragile as I only changed one > initialization method and if I would have liked to change them all, I > would have to duplicate a lot of code. > > Would it be possible to create a protected method which centralizes > the call to Bootstrap.getEntityManagerFactoryBuilder( persistenceUnit, > integration, providedClassLoader ); call we could override easily? > See: > https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L129 > https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L150 > https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L157 > > This way I could simply override this method to return a different > EntityManagerFactoryBuilder aware of my interceptor for every way to > initialize an EntityManagerFactory. > > And minor nitpicking, I think the wrap method should be protected as > it's used in a protected method we might want to tweak without having > to implement this method again. see > https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L137 > > I can open a Jira issue and do the work if you agree there is > something to fix and we come up with a plan (and a clever method > name). > > Thanks for your feedback. > > -- > Guillaume From emmanuel at hibernate.org Wed Mar 19 08:24:36 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 19 Mar 2014 13:24:36 +0100 Subject: [hibernate-dev] [OGM] Discussion on Neo4J mapping Message-ID: <20140319122436.GI41331@hibernate.org> Davide explained to me the mapping of entities and associations by the new Neo4J dialect. It is recorded here. Meeting ended Wed Mar 19 12:10:29 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-03-19-11.05.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-19-11.05.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-19-11.05.log.html From emmanuel at hibernate.org Wed Mar 19 09:45:17 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 19 Mar 2014 14:45:17 +0100 Subject: [hibernate-dev] DefaultLoadEventListener and second level cache In-Reply-To: References: Message-ID: <20140319134517.GK41331@hibernate.org> I talked with Guillaume. TwoPhaseLoad.doInitializeEntity from initializeEntity from Loader.initializeEntitiesAndCollections from Laoder.processResultSet form Loader.doQuery from doQueryAndInitializeNonLazyCollections from doQueryAndInitializeNonLazyCollections from Persister.load from DefaultLoadEventListener.loadFromDatasource On Wed 2014-03-19 11:55, Guillaume Smet wrote: > Hi, > > We have a lot of second level cache misses on one of our applications > and I wanted to understand why it was the case. These cache misses > happen even after loading twice the exact same page. They are coming > from entities which are loaded via DefaultLoadEventListener. > > I tried to debug it and was looking for the place where the entity is > put in the cache when the DefaultLoadEventListener path is used. > > Could someone point me to where we put the entity in the cache so that > I can try debugging further? > > Thanks in advance. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Mar 19 09:54:15 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Mar 2014 13:54:15 +0000 Subject: [hibernate-dev] Make HibernatePersistenceProvider easier to extend In-Reply-To: References: Message-ID: Hi Guillaume, looks like a good idea to me, but my advice would be to make all the changes and send a pull request: would make it easier to reason about the implications. You should either see it "just gets merged", os get some more concrete feedback.. Such an approach might make you occasionally code something which doesn't get included, but it's rare to hit and actual deal breaker and I'd argue it's never entirely a waste of time to play with refactorings and iterate multiple times. We all learn from it. Cheers, Sanne On 19 March 2014 11:10, Guillaume Smet wrote: > Hi, > > Any thoughts on this one? > > I have bandwidth this week if it's considered something we want. > > Thanks. > > On Thu, Jan 23, 2014 at 2:08 PM, Guillaume Smet > wrote: >> Hi, >> >> I'm starting our migration to ORM 4.3 to be able to provide some >> (hopefully useful) feedback on ORM 4.3 and Search 4.5. >> >> One thing we did in most of our apps was injecting Spring managed >> interceptor into the session factory using a trick very similar to >> what is explained there: >> http://blog.krecan.net/2009/01/24/spring-managed-hibernate-interceptor-in-jpa/. >> >> This (kinda ugly) trick doesn't work any more in 4.3 and I ended up >> doing the following: >> https://gist.github.com/gsmet/8578138 >> which works but is IMHO very fragile as I only changed one >> initialization method and if I would have liked to change them all, I >> would have to duplicate a lot of code. >> >> Would it be possible to create a protected method which centralizes >> the call to Bootstrap.getEntityManagerFactoryBuilder( persistenceUnit, >> integration, providedClassLoader ); call we could override easily? >> See: >> https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L129 >> https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L150 >> https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L157 >> >> This way I could simply override this method to return a different >> EntityManagerFactoryBuilder aware of my interceptor for every way to >> initialize an EntityManagerFactory. >> >> And minor nitpicking, I think the wrap method should be protected as >> it's used in a protected method we might want to tweak without having >> to implement this method again. see >> https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/HibernatePersistenceProvider.java#L137 >> >> I can open a Jira issue and do the work if you agree there is >> something to fix and we come up with a plan (and a clever method >> name). >> >> Thanks for your feedback. >> >> -- >> Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Mar 19 10:56:23 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Mar 2014 14:56:23 +0000 Subject: [hibernate-dev] ci.hibernate.org and network port assignment In-Reply-To: References: Message-ID: Thanks Paolo! @All, since we now have a single executor on the CI server, I've enforced a 90 minutes timeout on the ORM build job (master) as it occasionally hangs. On 18 March 2014 22:49, Paolo Antinori wrote: > hi everyone, > > I'll be happy to help with the activity of isolating build job in docker > containers started directly via jenkins. > > The technology should allow concurrent build job totally isolated, as > anticipated. > > I am going to start with OGM that is the project I am more familiar with > and I will let you know of eventual achievement. > > > paolo > > > > I've created WEBSITE-178 [1] as once again we had testsuites failing > because of a network port being used by a different job; bad luck, but > we can do better. > > Assuming we want to use the Jenkins plugin "port allocator", this > would however need to be consistently honored by all builds we launch: > it passes variables which we should use, but it can't enforce them > AFAIK. > > Is that going to be maintanable in the long run? > > An alternative would be to consistently run each and every build in > its own isolated docker container, but > a) that's not something I can setup overnight > b) we'd need to use more complex build scripts, for example the nice > Maven and Gradle integrations with the Jenkins build configuration > would be unusable. > > We're having quite a list of services; even ignoring the OGM exotic > databases we have at least: > - Byteman > - JGroups > - Arquillian > - WildFly > - ActiveMQ (JMS tests in Search) > - ... ? > > To fight the urgent need, I'm going to prevent parallelism of any > build. Let's hope ORM's master doesn't get stuck, as everything else > would be blocked. I really hope this measure stays as temporary as > possible :-/ > > -- Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at hibernate.org Wed Mar 19 12:25:29 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 19 Mar 2014 17:25:29 +0100 Subject: [hibernate-dev] Bytecode enhancement Message-ID: Hi, I took a look at the bytecode enhancement Maven plugin and I also have this issue https://hibernate.atlassian.net/browse/HHH-8833 . As far as I can tell the Maven plugin (and I suppose the Gradle plugin too) doesn't provide any information about the classpath so it's impossible to use the bytecode enhancement plugin in real life applications because you obviously have dependencies to other classes. Is this something supported or something very experimental? I found some old posts of Emmanuel discouraging the use of bytecode enhancement so I'm not sure it's a good idea to invest our time in it? Basically, we have a lot of nullable @OneToOne properties and as far as I understood it, it's supposed to help this case a lot. Maybe using something like http://www.mograblog.com/2010/01/setting-classloader-in-maven-plugin.html might be a good idea for the Maven plugin? Anyway feedback welcome before we invest time in it. Thanks. -- Guillaume From emmanuel at hibernate.org Wed Mar 19 13:00:37 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 19 Mar 2014 18:00:37 +0100 Subject: [hibernate-dev] ci.hibernate.org and network port assignment In-Reply-To: References: Message-ID: <20140319170037.GL41331@hibernate.org> Is it possible to do something a little smarter and let the website jobs run in parallel to this port cock fight builds? I got stuck behind an ORM job that turn out to just fail after 30 mins for some reasons I did not get. Emmanuel On Wed 2014-03-19 14:56, Sanne Grinovero wrote: > Thanks Paolo! > > @All, since we now have a single executor on the CI server, I've > enforced a 90 minutes timeout on the ORM build job (master) as it > occasionally hangs. > > On 18 March 2014 22:49, Paolo Antinori wrote: > > hi everyone, > > > > I'll be happy to help with the activity of isolating build job in docker > > containers started directly via jenkins. > > > > The technology should allow concurrent build job totally isolated, as > > anticipated. > > > > I am going to start with OGM that is the project I am more familiar with > > and I will let you know of eventual achievement. > > > > > > paolo > > > > > > > > I've created WEBSITE-178 [1] as once again we had testsuites failing > > because of a network port being used by a different job; bad luck, but > > we can do better. > > > > Assuming we want to use the Jenkins plugin "port allocator", this > > would however need to be consistently honored by all builds we launch: > > it passes variables which we should use, but it can't enforce them > > AFAIK. > > > > Is that going to be maintanable in the long run? > > > > An alternative would be to consistently run each and every build in > > its own isolated docker container, but > > a) that's not something I can setup overnight > > b) we'd need to use more complex build scripts, for example the nice > > Maven and Gradle integrations with the Jenkins build configuration > > would be unusable. > > > > We're having quite a list of services; even ignoring the OGM exotic > > databases we have at least: > > - Byteman > > - JGroups > > - Arquillian > > - WildFly > > - ActiveMQ (JMS tests in Search) > > - ... ? > > > > To fight the urgent need, I'm going to prevent parallelism of any > > build. Let's hope ORM's master doesn't get stuck, as everything else > > would be blocked. I really hope this measure stays as temporary as > > possible :-/ > > > > -- Sanne > > _______________________________________________ > > 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 emmanuel at hibernate.org Wed Mar 19 13:06:13 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 19 Mar 2014 18:06:13 +0100 Subject: [hibernate-dev] Bytecode enhancement In-Reply-To: References: Message-ID: <20140319170613.GM41331@hibernate.org> My comment about bytecode enhancement was at a time where Hibernate ORM did not make as much optimizations as it does now. In an ideal world, the bytecode enhancement is triggered at startup time like we do for Java EE. I am not sure if that's doable in your environment though. On Wed 2014-03-19 17:25, Guillaume Smet wrote: > Hi, > > I took a look at the bytecode enhancement Maven plugin and I also have > this issue https://hibernate.atlassian.net/browse/HHH-8833 . > > As far as I can tell the Maven plugin (and I suppose the Gradle plugin > too) doesn't provide any information about the classpath so it's > impossible to use the bytecode enhancement plugin in real life > applications because you obviously have dependencies to other classes. > > Is this something supported or something very experimental? I found > some old posts of Emmanuel discouraging the use of bytecode > enhancement so I'm not sure it's a good idea to invest our time in it? > > Basically, we have a lot of nullable @OneToOne properties and as far > as I understood it, it's supposed to help this case a lot. > > Maybe using something like > http://www.mograblog.com/2010/01/setting-classloader-in-maven-plugin.html > might be a good idea for the Maven plugin? > > Anyway feedback welcome before we invest time in it. > > Thanks. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Mar 19 13:15:29 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Mar 2014 17:15:29 +0000 Subject: [hibernate-dev] ci.hibernate.org and network port assignment In-Reply-To: <20140319170037.GL41331@hibernate.org> References: <20140319170037.GL41331@hibernate.org> Message-ID: On 19 March 2014 17:00, Emmanuel Bernard wrote: > Is it possible to do something a little smarter and let the website jobs > run in parallel to this port cock fight builds? > I got stuck behind an ORM job that turn out to just fail after 30 mins > for some reasons I did not get. Good point: fixed it. Jenkins is now capped to 5 parallel Executors, but any build using ports will require 3 of them. -- Sanne > > Emmanuel > > On Wed 2014-03-19 14:56, Sanne Grinovero wrote: >> Thanks Paolo! >> >> @All, since we now have a single executor on the CI server, I've >> enforced a 90 minutes timeout on the ORM build job (master) as it >> occasionally hangs. >> >> On 18 March 2014 22:49, Paolo Antinori wrote: >> > hi everyone, >> > >> > I'll be happy to help with the activity of isolating build job in docker >> > containers started directly via jenkins. >> > >> > The technology should allow concurrent build job totally isolated, as >> > anticipated. >> > >> > I am going to start with OGM that is the project I am more familiar with >> > and I will let you know of eventual achievement. >> > >> > >> > paolo >> > >> > >> > >> > I've created WEBSITE-178 [1] as once again we had testsuites failing >> > because of a network port being used by a different job; bad luck, but >> > we can do better. >> > >> > Assuming we want to use the Jenkins plugin "port allocator", this >> > would however need to be consistently honored by all builds we launch: >> > it passes variables which we should use, but it can't enforce them >> > AFAIK. >> > >> > Is that going to be maintanable in the long run? >> > >> > An alternative would be to consistently run each and every build in >> > its own isolated docker container, but >> > a) that's not something I can setup overnight >> > b) we'd need to use more complex build scripts, for example the nice >> > Maven and Gradle integrations with the Jenkins build configuration >> > would be unusable. >> > >> > We're having quite a list of services; even ignoring the OGM exotic >> > databases we have at least: >> > - Byteman >> > - JGroups >> > - Arquillian >> > - WildFly >> > - ActiveMQ (JMS tests in Search) >> > - ... ? >> > >> > To fight the urgent need, I'm going to prevent parallelism of any >> > build. Let's hope ORM's master doesn't get stuck, as everything else >> > would be blocked. I really hope this measure stays as temporary as >> > possible :-/ >> > >> > -- Sanne >> > _______________________________________________ >> > 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 guillaume.smet at gmail.com Wed Mar 19 14:09:31 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 19 Mar 2014 19:09:31 +0100 Subject: [hibernate-dev] Bytecode enhancement In-Reply-To: <20140319170613.GM41331@hibernate.org> References: <20140319170613.GM41331@hibernate.org> Message-ID: On Wed, Mar 19, 2014 at 6:06 PM, Emmanuel Bernard wrote: > My comment about bytecode enhancement was at a time where Hibernate ORM > did not make as much optimizations as it does now. > In an ideal world, the bytecode enhancement is triggered at startup time > like we do for Java EE. I am not sure if that's doable in your > environment though. We are in a Tomcat + Spring environment so I don't think it's doable and we have to stick to compile time enhancement. I'll see if we can commit some time to put the Maven plugin in shape. -- Guillaume From guillaume.smet at gmail.com Wed Mar 19 14:12:13 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 19 Mar 2014 19:12:13 +0100 Subject: [hibernate-dev] Make HibernatePersistenceProvider easier to extend In-Reply-To: References: Message-ID: Hi Sanne, On Wed, Mar 19, 2014 at 2:54 PM, Sanne Grinovero wrote: > looks like a good idea to me, but my advice would be to make all the > changes and send a pull request: would make it easier to reason about > the implications. Well, it's more that I wasn't sure it was worth wasting your time with such a PR. Anyway, done: - https://hibernate.atlassian.net/browse/HHH-9067 - https://github.com/hibernate/hibernate-orm/pull/713 I added to the JIRA issue an example of what we do with this. It seems to be a common need in the Spring world as there are several articles out there on how to do it with ORM pre 4.3. -- Guillaume From ales.justin at gmail.com Wed Mar 19 14:57:57 2014 From: ales.justin at gmail.com (Ales Justin) Date: Wed, 19 Mar 2014 19:57:57 +0100 Subject: [hibernate-dev] Bytecode enhancement In-Reply-To: References: <20140319170613.GM41331@hibernate.org> Message-ID: Perhaps see if this can be of any use to you: * https://github.com/alesj/maven-transformer-plugin I'm using this as part of CapeDwarf's GAE jar transformation. * https://github.com/capedwarf/capedwarf-blue/blob/master/bytecode/src/main/java/org/jboss/capedwarf/bytecode/CapedwarfTransformerMojo.java > On Mar 19, 2014, at 19:09, Guillaume Smet wrote: > > On Wed, Mar 19, 2014 at 6:06 PM, Emmanuel Bernard > wrote: >> My comment about bytecode enhancement was at a time where Hibernate ORM >> did not make as much optimizations as it does now. >> In an ideal world, the bytecode enhancement is triggered at startup time >> like we do for Java EE. I am not sure if that's doable in your >> environment though. > > We are in a Tomcat + Spring environment so I don't think it's doable > and we have to stick to compile time enhancement. > > I'll see if we can commit some time to put the Maven plugin in shape. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From alex.snaps at gmail.com Wed Mar 19 17:13:39 2014 From: alex.snaps at gmail.com (Alex Snaps) Date: Wed, 19 Mar 2014 17:13:39 -0400 Subject: [hibernate-dev] jsr107 Message-ID: Hey everyone, I wondered if anyone had considered (even the feasibility of) moving the Caching SPI of Hibernate to use the (now released!) jcache API of JSR107? I was contemplating having a look at providing a "jsr107 caching provider" maybe first, which then could maybe folded into Hibernate... Anyways, random thoughts, maybe some of you already have insights. Also, I'd expect that (some) "cache vendors" might want to do some tuning based on the Hibernate usecase still, so maybe the idea isn't such a great one (if even feasible again, as I didn't even look into that). Anyways... further random thoughts on the subject welcome, even non-random ones actually. Alex -- Alex Snaps Principal Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps http://withinthefra.me From emmanuel at hibernate.org Thu Mar 20 10:08:32 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 20 Mar 2014 15:08:32 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> Message-ID: <20140320140832.GB4298@hibernate.org> On Tue 2014-03-18 18:26, Guillaume Smet wrote: > Hi, > > On Tue, Mar 4, 2014 at 7:06 PM, Guillaume Smet wrote: > > I'll post as soon as I have a working prototype of what I would like > > to achieve and then we can discuss from there. > > I finally succeeded in committing a few hours to prototype what I have in mind: > https://github.com/openwide-java/hibernate-search/commits/prototype-plain-text-search > > It's a very simple patch. I added a test case to the DSLTest. > > It's a work in progress but I think it might be easier to understand > what I have in mind once you have taken a look at this. > > I needed the SimpleQueryParser of Lucene 4.7 so I included it: it's a > vanilla version so we can remove it after the move to 4.7. > > What I would like to do: > - add the ability to indicate that you want a fuzzy search for a given > field in the DSL > - I don't like the withAllTerms() option. I would like this behavior > to be the default and to have something like "defaultOperatorIsOr()": > it defines the default operator when you don't use an explicit one. > I'm not sure defaultOperatorIsOr() is something > acceptable/understandable. I tend to disagree with you. The SimpleQueryBuilder seems to disagree with you too as SHOULD is the default. Care to give your arguments in favor of a different value for the default? > > Where I would like advice/opinion: > - does it look like a good idea or something horrible? Yes that looks interesting to me. This machine is hard to describe to a human though except with "it does the right thing... most of the time" :) > - I'm still hesitant about what to do with field bridges: atm, I don't > take them into account at all The way I look at it, you won't likely be able to support fields that are not texts in the first place. So you could raise some exception if a selected field is not a String field bridge. And we can expand from there. You will get more info once field and class bridges expose more metadata. > - I think having a DSL branch for text search is necessary even if it > might seem very similar to term search I feel that you are right on that one but can you try and write down your arguments? Note that the QueryBuilder.createFieldQuery seems to do the right thing when it comes to applying SHOULD between overlapping tokens and the selected operator between "words" but I did not dive too much into the logic. From emmanuel at hibernate.org Thu Mar 20 10:10:30 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 20 Mar 2014 15:10:30 +0100 Subject: [hibernate-dev] jsr107 In-Reply-To: References: Message-ID: <20140320141030.GC4298@hibernate.org> My guts are that each cache will want to provide a specific implementation but it would be nice to have a generic albeit less than ideal 107 implementation. Nobody has started this work AFAIK so you're very welcome :) Emmanuel On Wed 2014-03-19 17:13, Alex Snaps wrote: > Hey everyone, > I wondered if anyone had considered (even the feasibility of) moving the > Caching SPI of Hibernate to use the (now released!) jcache API of JSR107? > I was contemplating having a look at providing a "jsr107 caching provider" > maybe first, which then could maybe folded into Hibernate... Anyways, > random thoughts, maybe some of you already have insights. Also, I'd expect > that (some) "cache vendors" might want to do some tuning based on the > Hibernate usecase still, so maybe the idea isn't such a great one (if even > feasible again, as I didn't even look into that). Anyways... further random > thoughts on the subject welcome, even non-random ones actually. > Alex > > -- > Alex Snaps > Principal Software Engineer - Terracotta > http://twitter.com/alexsnaps > http://www.linkedin.com/in/alexsnaps > http://withinthefra.me > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From alex.snaps at gmail.com Thu Mar 20 10:28:02 2014 From: alex.snaps at gmail.com (Alex Snaps) Date: Thu, 20 Mar 2014 10:28:02 -0400 Subject: [hibernate-dev] jsr107 In-Reply-To: <20140320141030.GC4298@hibernate.org> References: <20140320141030.GC4298@hibernate.org> Message-ID: Started yesterday night actually... I'm going to move forward as straightforward as possible and then probably get together with Infinispan guys while myself looking at it from Ehcache's perspective. Basically, I _hope_ we can have the hibernate-jcache module be "open" enough to provide "extension points" for specific implementation to "tune" better. I guess it will also depend how cache vendors will go about 107. For implementation that "merely" wrap their own API with 107's the added layer would just be overhead probably. Anyways, I'll move forward and share the new module when completed. On Thu, Mar 20, 2014 at 10:10 AM, Emmanuel Bernard wrote: > My guts are that each cache will want to provide a specific > implementation but it would be nice to have a generic albeit less than > ideal 107 implementation. > Nobody has started this work AFAIK so you're very welcome :) > > Emmanuel > > On Wed 2014-03-19 17:13, Alex Snaps wrote: > > Hey everyone, > > I wondered if anyone had considered (even the feasibility of) moving the > > Caching SPI of Hibernate to use the (now released!) jcache API of JSR107? > > I was contemplating having a look at providing a "jsr107 caching > provider" > > maybe first, which then could maybe folded into Hibernate... Anyways, > > random thoughts, maybe some of you already have insights. Also, I'd > expect > > that (some) "cache vendors" might want to do some tuning based on the > > Hibernate usecase still, so maybe the idea isn't such a great one (if > even > > feasible again, as I didn't even look into that). Anyways... further > random > > thoughts on the subject welcome, even non-random ones actually. > > Alex > > > > -- > > Alex Snaps > > Principal Software Engineer - Terracotta > > http://twitter.com/alexsnaps > > http://www.linkedin.com/in/alexsnaps > > http://withinthefra.me > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Alex Snaps Principal Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps http://withinthefra.me From sanne at hibernate.org Thu Mar 20 11:21:23 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 20 Mar 2014 15:21:23 +0000 Subject: [hibernate-dev] Lucene moving to Java7 Message-ID: The next minor release of Apache Lucene v. 4.8 will require Java7. The Lucene team has highlighted many good reasons for that, including some excellent improvements in sorting performance and reliability of IO operations: nice things we'd like to take advantage of. Objections against baseling Hibernate Search 5 to *require* Java7 too? We hardly have a choice, so objections better be good ;-) -- Sanne From jottinge at redhat.com Thu Mar 20 11:58:39 2014 From: jottinge at redhat.com (Joseph B. Ottinger) Date: Thu, 20 Mar 2014 11:58:39 -0400 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: Message-ID: <532B102F.7020000@redhat.com> On Thu 20 Mar 2014 11:21:23 AM EDT, Sanne Grinovero wrote: > The next minor release of Apache Lucene v. 4.8 will require Java7. > > The Lucene team has highlighted many good reasons for that, including > some excellent improvements in sorting performance and reliability of > IO operations: nice things we'd like to take advantage of. > > Objections against baseling Hibernate Search 5 to *require* Java7 too? > We hardly have a choice, so objections better be good ;-) > > -- Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev Heck, if I weren't careful I'd say move Hibernate to Java *8* -- but that'd be insane. :) Yes, move it to Java 7. -- It's not my fault that I can't draw the human posterior with a mouse. From sanne at hibernate.org Thu Mar 20 12:29:56 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 20 Mar 2014 16:29:56 +0000 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: <6AA88494-11DB-4F6D-98AD-70CB8862C0E5@redhat.com> References: <6AA88494-11DB-4F6D-98AD-70CB8862C0E5@redhat.com> Message-ID: Note this would affect only our upcoming Hibernate Search 5.0: it's a major release which breaks some backwards compatibility anyway. I guess that blasts any remaining concern? For the purpose of WFK users in maintenance mode I'll expect them to stay on previous Search version, on which we'll backport fixes as usual. But I also expect we'll eventually want to provide a "new" version to deliver the goodies of EE7, JPA 2.1, etc.. which all require JDK7 anyway (in the scope of WFK or anything else coming our way). Thanks all for the comments Sanne On 20 March 2014 16:04, Burr Sutter wrote: > Adding the WFK Mareks :-) > > The only potential problem that I see is backward incompatibility with WFK 2.0.0 and its supported frameworks through June 2015. > We do not require JVM upgrades, in production, for customers, within the "supported time window" - in our WFK case June 2012 to June 2015. > > > On Mar 20, 2014, at 11:21 AM, Sanne Grinovero wrote: > >> The next minor release of Apache Lucene v. 4.8 will require Java7. >> >> The Lucene team has highlighted many good reasons for that, including >> some excellent improvements in sorting performance and reliability of >> IO operations: nice things we'd like to take advantage of. >> >> Objections against baseling Hibernate Search 5 to *require* Java7 too? >> We hardly have a choice, so objections better be good ;-) >> >> -- Sanne > From guillaume.smet at gmail.com Thu Mar 20 13:50:32 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 20 Mar 2014 18:50:32 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: <20140320140832.GB4298@hibernate.org> References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> <20140320140832.GB4298@hibernate.org> Message-ID: On Thu, Mar 20, 2014 at 3:08 PM, Emmanuel Bernard wrote: > I tend to disagree with you. The SimpleQueryBuilder seems to disagree > with you too as SHOULD is the default. Care to give your arguments in > favor of a different value for the default? Well, IMHO, this feature is designed for a specific purpose and is not a general implementation. That's why I'm not considering me tied up by choices of general implementations. I think when a user is looking for "something precise", he wants results which satisfies his queries. That said I'm open to keep it the other way. It's just that I really prefer an AND default from a user point of view. FWIW every time we forgot to change the operator, we have a ticket open by our customers as soon as they search something. I was thinking about renaming the option: use(And|Or)AsDefaultOperator(). Not exactly elegant but it's what it really does. >> Where I would like advice/opinion: >> - does it look like a good idea or something horrible? > > Yes that looks interesting to me. This machine is hard to describe to a > human though except with "it does the right thing... most of the time" :) Yes, that's the purpose of this feature. From my point of view, if we consider one day that a eDismax parser is more suitable for it, we might move to this new parser. >> - I'm still hesitant about what to do with field bridges: atm, I don't >> take them into account at all > > The way I look at it, you won't likely be able to support fields that > are not texts in the first place. > So you could raise some exception if a selected field is not a > String field bridge. And we can expand from there. Will do. >> - I think having a DSL branch for text search is necessary even if it >> might seem very similar to term search > > I feel that you are right on that one but can you try and write down > your arguments? Well, there are a couple of good reasons AFAICS: - text() implementation is limited (see the FieldBridge limitation above) and totally different from the term() one. I really don't like the idea to expose it to the user as an option to the term() search. It's definitely a totally different thing and it's important to show it; - in the long term, I'm not sure the choices made for text() and term() will be the same. We might want to add option to one or another and not both. This second reason is kinda related to the first one. Typically, I would like to add a minimum should match option one day. > Note that the QueryBuilder.createFieldQuery seems to do the right thing > when it comes to applying SHOULD between overlapping tokens and the > selected operator between "words" but I did not dive too much into the > logic. Yep. That's one of the reasons why I want to use the Lucene machinery. I'm not sure QueryBuilder.createFieldQuery *always* does the right thing but it's certainly far better than the naive approach. -- Guillaume From hardy at hibernate.org Thu Mar 20 14:20:22 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 20 Mar 2014 19:20:22 +0100 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: Message-ID: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> +100 On 20 Jan 2014, at 16:21, Sanne Grinovero wrote: > The next minor release of Apache Lucene v. 4.8 will require Java7. > > The Lucene team has highlighted many good reasons for that, including > some excellent improvements in sorting performance and reliability of > IO operations: nice things we'd like to take advantage of. > > Objections against baseling Hibernate Search 5 to *require* Java7 too? > We hardly have a choice, so objections better be good ;-) > > -- Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Thu Mar 20 18:05:23 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 20 Mar 2014 23:05:23 +0100 Subject: [hibernate-dev] Session and carrying 3rd party state Message-ID: <20140320220523.GC10878@hibernate.org> I took some more time to think about our conversation from 2 IRC meeting ago about offering the ability to carry session bound state not related to ORM per se. Below is a sum and a potential solution. If you are short on time, read Goals, then the SessionSessionEventListener approach and ignore the rest. ## Goals The goal is to be able to carry session bound state for non-ORM projects like search and OGM. We want to avoid ThreadLocal use, in particular when it cannot be protected by a try / catch for proper resource cleaning. We want to avoid a structure that would be shared across threads concurrently i.e. using ConcurrentHashMap with a Weak reference to the session. It needs to be informed of a call to session.clear() It needs to be informed of a call to session.close() The state needs to be accessed from event listener implementations and custom persister / loader implementations i.e. SessionImplementor and maybe EventSource? ## Approaches I'll discuss the approaches we explored in the meeting and then offer an alternative one that I think is pretty interesting and fit better with the current Session model. ### Map This is essentially sticking a map on SessionImpl and use it to carry state. The following is a pseudo implementation /** * interface implemented by SessionImpl and the like */ interface SessionCompanion { Object getCompanion(String key); void addCompanion(String key, Object companion); void removeCompanion(String key); } /** * adds a map to the SessionImpl */ SessionImpl { private Map companions; public Object getCompanion(String key) { return companions.get(key); } public void addCompanion(String key, Object value) { companions.add(key, companion); } public void removeCompanion(String key) { companions.remove(key) } } The persister or event listener would call SessionCompation.*Companion method to put and retrieve its state. There is no clear / close event listener loop and it would need to be added. ### Delegator Gunnar and teve discussed an approach where the delegator would be passed to the underlying session and be accessible via an `unwrap` method. I have not followed the details but this approach has one major flaw: the delegator (OgmSession, FullTextSession etc) is not always created and thus would not be necessarily available. A somewhat similar idea involving passing the session owner has the same drawback. And another one described by Gunnar in https://hibernate.atlassian.net/browse/OGM-469 ### The type-safe map approach This approach is vaguely similar to the Map approach except that the payload is represented and looked up by Class. This has the benefit of not having namespace problems and is generally less String-y. /** * interface implemented by SessionImpl and the like */ interface SessionCompanion { T getCompanion(Class type); void addCompanion(Object companion); void removeCompanion(Class type) } SessionImpl { //could also use an array or an ArrayList private Map, Object> companions; public T getCompanion(Class type) { return (T) companions.get(type); } public void addCompanion(Object companion) { companions.add(companion.getClass(), type); } public void removeCompanion(Class type) { companions.remove(type); } } Like in the Map approach, the persister or custom event listener would interact with SessionCompanion. There are open issues like what should be done when two objects of the same type are added to the same session. Likewise the clear / close hook issues need to be addressed. ### the SessionEventListener approach I did not know but there is a concept of `SessionEventListener` which can be added to a `SessionImplementor`. It has hooks that are addressing most of the goals. //interface already exists interface SessionImplementor { public SessionEventListenerManager getEventListenerManager(); } //interface already exists public interface SessionEventListenerManager extends SessionEventListener { // add this method to be able to retrieve a specific listener holding some state for a 3rd party project List getSessionEventListeners(); } OGM or Search would implement a `SessionEventListener` and attach an instance to a session via `Session.addEventListeners()`. It would require to add a method to retrieve the list of `SessionEventListener`s attached to a `SessionEventListenerManager`. List listeners = sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); OgmSessionEventListener ogmListener = findOrAddOgmListener(sessionImplementor, listeners); ogmListener.someStuff(); ## What about clear and close? We have a few ways to react to these. SessionEventListener is already called back when a flush begins / ends as well as when Session closes. We need to either: - add a clear begins / ends callback - have the third party project add a ClearEventListener which would access the SessionEventListeners and do some magic. The first approach has my preference and would do: public interface SessionEventListener { [...] void clearStart(); void clearEnd(); } What do you guys think? The SessionEventListener approach feels more natural. Emmanuel From guillaume.smet at hibernate.org Fri Mar 21 06:10:57 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Fri, 21 Mar 2014 11:10:57 +0100 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions Message-ID: Hi, = Context = So, my patch here [1] broke a test which checks that Criteria + restrictions mostly work - even if it's documented as not supported and not working. "Mostly" as in "you can't get the result size but you might get the results". See [2] for explanations. I spent some time yesterday contemplating this issue and, while I'm sorry for breaking this test, I still think we should apply my patch, remove this test and make this case not supported for good. = Why it mostly works = In the original ObjectLoaderHelper implementation, we use session.load: it doesn't force the proxy to be initialized. If a proxy for an entity isn't initialized, it's filtered out from the results. It's the job of the various implementations of ObjectsInitializer to initialize the objects in the session so that they are later included in the results. In the case of Criteria + restrictions, the restrictions are applied in the ObjectsInitializer so the entity which doesn't satisfy the restrictions are not initialized in the ObjectsInitializer... and thus not included in the results. = Why my patch is breaking this behaviour consistently = In my patch, I use Session.get which forces the initialization of the proxy and I removed the filter removing the uninitialized proxies: it became unnecessary as I was sure all proxies are now initialized. This patch has been designed to solve HSEARCH-1448 and to simplify the ObjectLoaderHelper code which was quite complicated. Situation after my patch: all the results satisfying the full text search are returned. The restrictions of the criteria are not taken into account. In fact, it works as documented. = Relying on the session state to filter out entities is wrong = So the fact is that we basically rely on the session state to filter out the results we don't want. I had to check that my gut feeling was right so I checked out current master, opened ResultSizeOnCriteriaTest and just added the following lines before the search call: //load in the session the object which shouldn't be returned just for fun session.get( Tractor.class, 2 ); -> the object is returned and the test is broken too. This is expected behaviour as this object has been initialized in the session and is now considered as a valid candidate for the results. = Conclusion = I don't think we can have a really working criteria + restrictions thing without refactoring a lot of things in search: the Initializer + Loader concept can't work reliably in this case. Therefore I think we should simply remove this test and clearly make it fail as it can be a potential security flaw if we return entities the user shouldn't see just because they were initialized in the session for another purpose. We might revisit it later but I really think it's a lot of work to get it right. Thoughts? References [1] https://github.com/hibernate/hibernate-search/pull/581 [2] https://hibernate.atlassian.net/browse/HSEARCH-753 From hardy at hibernate.org Fri Mar 21 07:14:30 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 21 Mar 2014 12:14:30 +0100 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions In-Reply-To: References: Message-ID: <8FFDADE9-AD89-4793-8B63-5B51F4C9FA1D@hibernate.org> Hi Guillaume, nice job with this issue. I was about to comment on the pull request, but now I do it here. On 21 Jan 2014, at 11:10, Guillaume Smet wrote: > So, my patch here [1] broke a test which checks that Criteria + > restrictions mostly work - even if it's documented as not supported > and not working. > > "Mostly" as in "you can't get the result size but you might get the > results". See [2] for explanations. > > I spent some time yesterday contemplating this issue and, while I'm > sorry for breaking this test, I still think we should apply my patch, > remove this test and make this case not supported for good I think you are right. I also would simplify the code and remove this test. The documentation is clear about this: "Only fetch mode can be adjusted, refrain from applying any other restriction.? I am even wondering whether we should not go a step further and disallow the use of Criterias altogether in FullTextSessionImpl by throwing an exception in case of its use. We then can add an explicit method to FullTextSession which allows just the setting of the fetch type for a given association of an entity. Under the hood it can still use the Criteria, but it will prevent the unsupported use of Criteria queries. +1 for applying the patch and removing the test and I probably would even go a step further. ?Hardy From steve at hibernate.org Fri Mar 21 07:48:33 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 21 Mar 2014 06:48:33 -0500 Subject: [hibernate-dev] jsr107 In-Reply-To: References: <20140320141030.GC4298@hibernate.org> Message-ID: Thanks for looking into this Alex. Like Emmanuel, I'd assume providers would want to leverage any advantages they see in their native APIs, but a 107-based cache implementation would certainly be useful. On Thu, Mar 20, 2014 at 9:28 AM, Alex Snaps wrote: > Started yesterday night actually... > I'm going to move forward as straightforward as possible and then probably > get together with Infinispan guys while myself looking at it from Ehcache's > perspective. > Basically, I _hope_ we can have the hibernate-jcache module be "open" > enough to provide "extension points" for specific implementation to "tune" > better. > I guess it will also depend how cache vendors will go about 107. For > implementation that "merely" wrap their own API with 107's the added layer > would just be overhead probably. > Anyways, I'll move forward and share the new module when completed. > > > On Thu, Mar 20, 2014 at 10:10 AM, Emmanuel Bernard > wrote: > > > My guts are that each cache will want to provide a specific > > implementation but it would be nice to have a generic albeit less than > > ideal 107 implementation. > > Nobody has started this work AFAIK so you're very welcome :) > > > > Emmanuel > > > > On Wed 2014-03-19 17:13, Alex Snaps wrote: > > > Hey everyone, > > > I wondered if anyone had considered (even the feasibility of) moving > the > > > Caching SPI of Hibernate to use the (now released!) jcache API of > JSR107? > > > I was contemplating having a look at providing a "jsr107 caching > > provider" > > > maybe first, which then could maybe folded into Hibernate... Anyways, > > > random thoughts, maybe some of you already have insights. Also, I'd > > expect > > > that (some) "cache vendors" might want to do some tuning based on the > > > Hibernate usecase still, so maybe the idea isn't such a great one (if > > even > > > feasible again, as I didn't even look into that). Anyways... further > > random > > > thoughts on the subject welcome, even non-random ones actually. > > > Alex > > > > > > -- > > > Alex Snaps > > > Principal Software Engineer - Terracotta > > > http://twitter.com/alexsnaps > > > http://www.linkedin.com/in/alexsnaps > > > http://withinthefra.me > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > Alex Snaps > Principal Software Engineer - Terracotta > http://twitter.com/alexsnaps > http://www.linkedin.com/in/alexsnaps > http://withinthefra.me > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Fri Mar 21 07:50:10 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 21 Mar 2014 12:50:10 +0100 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions In-Reply-To: <8FFDADE9-AD89-4793-8B63-5B51F4C9FA1D@hibernate.org> References: <8FFDADE9-AD89-4793-8B63-5B51F4C9FA1D@hibernate.org> Message-ID: Hi Hardy, On Fri, Mar 21, 2014 at 12:14 PM, Hardy Ferentschik wrote: > I am even wondering whether we should not go a step further and disallow > the use of Criterias altogether in FullTextSessionImpl by throwing an exception > in case of its use. We then can add an explicit method to FullTextSession which > allows just the setting of the fetch type for a given association of an entity. > Under the hood it can still use the Criteria, but it will prevent the unsupported use > of Criteria queries. Thanks for your feedback. As for me, I think generalizing what is done in FullTextQueryImpl.getResultSize() when isSizeSafe() is false might be sufficient for the moment. I don't use this option though so I don't know exactly why it's used and if being able to set a Criteria query might be useful. -- Guillaume From sanne at hibernate.org Fri Mar 21 08:41:29 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 21 Mar 2014 12:41:29 +0000 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions In-Reply-To: References: <8FFDADE9-AD89-4793-8B63-5B51F4C9FA1D@hibernate.org> Message-ID: The question of being able to filter via Criteria or Hibernate Session Filters is a recurring feature request so we need to be cautious here. You make good points, and if it comes to a choice of support either/or we'll certainly drop the Criteria filtering as obviously we won't make concessions on correctness. I'm sure that Criteria filtering is actually being used by several other teams, and while they are aware of it being "borderline", it's good enough for them; so rather than drop it I want to have a better look at alternatives; worst case I'll end up with a refreshed understanding of this code area. Ultimately if we decide to drop it altogether, we might want to remove the option of specifying the Criteria altogether in favor or a "fetch graph" hint from JPA 2.1: probably more suited for the purpose and gives no room for unpredictable behaviour. -- Sanne On 21 March 2014 11:50, Guillaume Smet wrote: > Hi Hardy, > > On Fri, Mar 21, 2014 at 12:14 PM, Hardy Ferentschik wrote: >> I am even wondering whether we should not go a step further and disallow >> the use of Criterias altogether in FullTextSessionImpl by throwing an exception >> in case of its use. We then can add an explicit method to FullTextSession which >> allows just the setting of the fetch type for a given association of an entity. >> Under the hood it can still use the Criteria, but it will prevent the unsupported use >> of Criteria queries. > > Thanks for your feedback. > > As for me, I think generalizing what is done in > FullTextQueryImpl.getResultSize() when isSizeSafe() is false might be > sufficient for the moment. > > I don't use this option though so I don't know exactly why it's used > and if being able to set a Criteria query might be useful. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Fri Mar 21 08:58:36 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 21 Mar 2014 13:58:36 +0100 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions In-Reply-To: References: <8FFDADE9-AD89-4793-8B63-5B51F4C9FA1D@hibernate.org> Message-ID: <9CCAFA22-9746-4112-96F0-6380E73000BF@hibernate.org> On 21 Jan 2014, at 13:41, Sanne Grinovero wrote: > The question of being able to filter via Criteria or Hibernate Session > Filters is a recurring feature request so we need to be cautious here. The question is can we support it properly (most notably correctly). > You make good points, and if it comes to a choice of support either/or > we'll certainly drop the Criteria filtering as obviously we won't make > concessions on correctness. > > I'm sure that Criteria filtering is actually being used by several > other teams, and while they are aware of it being "borderline", it's > good enough for them; so rather than drop it I want to have a better > look at alternatives; worst case I'll end up with a refreshed > understanding of this code area. sure, another look cannot hurt. > Ultimately if we decide to drop it altogether, we might want to remove > the option of specifying the Criteria altogether in favor or a "fetch > graph" hint from JPA 2.1: probably more suited for the purpose and > gives no room for unpredictable behaviour. Good idea. Maybe I was too extreme with suggesting to throw an exception when using Criteria, but adding a decocted and predictable way for specifying fetch behaviour seems like the way forward. If nothing else we can then remove the mention of Criteria from the documentation in favour of the new dedicated API. If then someone wants to use Criteria he really does it on its on risk. ?Hardy From emmanuel at hibernate.org Fri Mar 21 09:51:01 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 21 Mar 2014 14:51:01 +0100 Subject: [hibernate-dev] [AND] Search: changing the way we search In-Reply-To: References: <26F2187B-9693-47C7-8A73-EE3C905FC0E5@hibernate.org> <6275C044-5423-49A4-A6C3-33C606C10074@hibernate.org> <20140320140832.GB4298@hibernate.org> Message-ID: <20140321135101.GA15656@hibernate.org> On Thu 2014-03-20 18:50, Guillaume Smet wrote: > On Thu, Mar 20, 2014 at 3:08 PM, Emmanuel Bernard > wrote: > > I tend to disagree with you. The SimpleQueryBuilder seems to disagree > > with you too as SHOULD is the default. Care to give your arguments in > > favor of a different value for the default? > > Well, IMHO, this feature is designed for a specific purpose and is not > a general implementation. That's why I'm not considering me tied up by > choices of general implementations. > > I think when a user is looking for "something precise", he wants > results which satisfies his queries. My problem is that when I look at that feature, it seems to me it is the backend of the Google Search form input. And SHOULD is a better default. The feature does not convey that you want "something precise". At least not more than any other query. Your use case AFAIUI is that you want results that do match for sure and nothing else. I'd love for us to massage the API to allow both ideas to be expressed naturally and also keep the doors opened to a dismax approach with shoulds but with at least n matches. I have no idea to how to express that yet. From emmanuel at hibernate.org Fri Mar 21 10:01:02 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 21 Mar 2014 15:01:02 +0100 Subject: [hibernate-dev] [Search] The case against searching with Criteria + restrictions In-Reply-To: References: Message-ID: <20140321140102.GB15656@hibernate.org> I don't ahve much to say besides what has been said on this thread already. The "tolerated" feature works in less cases than I anticipated as Guillaume demonstrated. The different with the new patch is that it happens systematically (on criteria restrictions) and leads to a lot of unitary entity loads. In other words, it wronger and slower :) A proper implementation of this feature, would require a redesign of the query SPIs I suppose. Emmanuel On Fri 2014-03-21 11:10, Guillaume Smet wrote: > Hi, > > = Context = > > So, my patch here [1] broke a test which checks that Criteria + > restrictions mostly work - even if it's documented as not supported > and not working. > > "Mostly" as in "you can't get the result size but you might get the > results". See [2] for explanations. > > I spent some time yesterday contemplating this issue and, while I'm > sorry for breaking this test, I still think we should apply my patch, > remove this test and make this case not supported for good. > > = Why it mostly works = > > In the original ObjectLoaderHelper implementation, we use > session.load: it doesn't force the proxy to be initialized. If a proxy > for an entity isn't initialized, it's filtered out from the results. > > It's the job of the various implementations of ObjectsInitializer to > initialize the objects in the session so that they are later included > in the results. > > In the case of Criteria + restrictions, the restrictions are applied > in the ObjectsInitializer so the entity which doesn't satisfy the > restrictions are not initialized in the ObjectsInitializer... and thus > not included in the results. > > = Why my patch is breaking this behaviour consistently = > > In my patch, I use Session.get which forces the initialization of the > proxy and I removed the filter removing the uninitialized proxies: it > became unnecessary as I was sure all proxies are now initialized. > > This patch has been designed to solve HSEARCH-1448 and to simplify the > ObjectLoaderHelper code which was quite complicated. > > Situation after my patch: all the results satisfying the full text > search are returned. The restrictions of the criteria are not taken > into account. In fact, it works as documented. > > = Relying on the session state to filter out entities is wrong = > > So the fact is that we basically rely on the session state to filter > out the results we don't want. > > I had to check that my gut feeling was right so I checked out current > master, opened ResultSizeOnCriteriaTest and just added the following > lines before the search call: > //load in the session the object which shouldn't be returned just for fun > session.get( Tractor.class, 2 ); > > -> the object is returned and the test is broken too. This is expected > behaviour as this object has been initialized in the session and is > now considered as a valid candidate for the results. > > = Conclusion = > > I don't think we can have a really working criteria + restrictions > thing without refactoring a lot of things in search: the Initializer + > Loader concept can't work reliably in this case. > > Therefore I think we should simply remove this test and clearly make > it fail as it can be a potential security flaw if we return entities > the user shouldn't see just because they were initialized in the > session for another purpose. > > We might revisit it later but I really think it's a lot of work to get it right. > > Thoughts? > > References > > [1] https://github.com/hibernate/hibernate-search/pull/581 > [2] https://hibernate.atlassian.net/browse/HSEARCH-753 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Tue Mar 25 05:25:22 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 25 Mar 2014 10:25:22 +0100 Subject: [hibernate-dev] [OGM] Move container integration test to a separate default test cycle Message-ID: <20140325092522.GA41254@hibernate.org> This is a follow up on https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092 We keep piling up new backends, new containers to test and new rules checked at build time. A consequence is that it is becoming less and less pleasant to work on OGM. You can see that n version of Naked+WF+EAP+... multiplied by m backends simply will make this project horrendously slow to contribute to. I imagine n = 3 or 4 and m = 10 in a medium term. I see two options that would keep us around for a while: 1. Make the container integration tests only run with a specific option activated on the CI. 2. Move the container integration tests outside in a different repo altogether. I do prefer 1. Emmanuel From sanne at hibernate.org Tue Mar 25 07:31:54 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 25 Mar 2014 11:31:54 +0000 Subject: [hibernate-dev] [OGM] Move container integration test to a separate default test cycle In-Reply-To: <20140325092522.GA41254@hibernate.org> References: <20140325092522.GA41254@hibernate.org> Message-ID: My vote goes to #1 as well for the short term. There also is a third option, which requires some more work but provides a very nice balance. A great deal of the slowness of this complex matrix execution can be addressed to the continuous startup and teardown of services like the various databases and the datastores. Considering that each of those services starts in less than a second, the problem is not the single startup but literally the compound effect of the complex matrix: if we started say MongoDB, and CouchDb, and all others, and all containers at the beginning of the suite, we could then run matrix tests in a very efficient way, I'd bet we could keep the full matrix *and* the testsuite under a single minute. The goal would be to reuse a single WildFly (or EAP) startup to test on each database; i.e. we need to share the running containers across modules, or merge the integration tests in a single module per container. Not sure how far Maven will be a problem for this. For the OGM needs to test on EAP, I just dicussed with Davide (same office today), and since we'd be testing an old version of EAP (6.1.0.Alpha1 being the latest in public Maven repositories), our idea is that this is too old to be useful anyway. We'll set up a profile - disabled by default - which downloads and tests latest EAP to be used by the Jenkins instance running at Red Hat. Sanne On 25 March 2014 09:25, Emmanuel Bernard wrote: > This is a follow up on > https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092 > > We keep piling up new backends, new containers to test and new rules > checked at build time. A consequence is that it is becoming less and > less pleasant to work on OGM. > > You can see that n version of Naked+WF+EAP+... multiplied by m backends > simply will make this project horrendously slow to contribute to. > I imagine n = 3 or 4 and m = 10 in a medium term. > > I see two options that would keep us around for a while: > > 1. Make the container integration tests only run with a specific option > activated on the CI. > 2. Move the container integration tests outside in a different repo > altogether. > > I do prefer 1. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Mar 25 12:52:10 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 25 Mar 2014 11:52:10 -0500 Subject: [hibernate-dev] IRC Developer Meeting - 3/25 Message-ID: [11:50] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-25-15.49.html [11:50] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-25-15.49.txt [11:50] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-25-15.49.log.html From hardy at hibernate.org Tue Mar 25 17:11:18 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 25 Mar 2014 22:11:18 +0100 Subject: [hibernate-dev] [Search] OSGi split packages Message-ID: Hi there, As part of my work for making Search OSGi ready [1], I am looking into addressing HSEARCH-1560 [2] which is about split packages which we have between some of our Search bundles (or modules to use Maven lingo). Basically a split package "is caused where two or more bundles export the same package name and version, usually with different contents?. [3] In terms of OSGi, split packages are bad and should be avoided. There exists a work around [3], but afaiu it is frowned upon. While working on an integration test trying to run Search in Apache Karaf, I was running into this problem and basically needed (for the time being) revert to the mentioned work around. The biggest for getting rid of split packages is org.hibernate.search which is a split packages between the engine and orm bundle. In org.hibernate.search of engine we have: - Environment, - FullTextFilter, - ProjectionConstants, - SearchException, - SearchFactory - Version. org.hibernate.search of orm contains: - FullTextQuery, - FullTextSession, - FullTextSharedSessionBuilder, - MassIndexer - Search. As you can see, these are quite central classes and moving any of them around will break existing code (even though updating just requires to change import statements). If we are serious with OSGi we should address this. We always said, that Search 5 is the release where we can break API backwards compatibility. So if we want to do this, we should do it now. On the other hand, it is a big change. I went ahead and tried to refactor org.hibernate.search in engine, applying the following changes: org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter org.hibernate.search.Version -> org.hibernate.search.engine.Version Some of these changes I actually find quite fitting independently of the split package problem. FullTextFilter seems to have found its true home now and Version and Environment don?t seem too bad either. The big change is SearchFactory and .SearchException. WDYT? Is this package refactoring something worth doing and if so what do you think about the new locations of the classes? Any better suggestions? Or do you think the orm bundle should be refactored instead? You can see the preliminary result here [4]. ?Hardy [1] https://hibernate.atlassian.net/browse/HSEARCH-1465 [2] https://hibernate.atlassian.net/browse/HSEARCH-1560 [3] http://wiki.osgi.org/wiki/Split_Packages [4] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-1560 From steve at hibernate.org Wed Mar 26 00:13:30 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 25 Mar 2014 23:13:30 -0500 Subject: [hibernate-dev] Another @Access quandry Message-ID: >From the test org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride we have the following: @Entity @Access(AccessType.PROPERTY) public class Course3 { private long id; ... @Id @GeneratedValue @Access(AccessType.FIELD) public long getId() { return id; } ... } The test asserts that this is a valid mapping. Granted that the spec is very unclear here, so I might be missing something. The pertinent spec section here states: *When Access(PROPERTY) is applied to an entity class, mapped superclass, or embeddableclass, mapping annotations may be placed on the properties of that class, and the persistenceprovider runtime accesses persistent state via the properties defined by that class. All proper-ties that are not annotated with the Transient annotation are persistent. WhenAccess(PROPERTY) is applied to such a class, it is possible to selectively designate indi-vidual attributes within the class for instance variable access. To specify a persistent instancevariable for access by the persistence provider runtime, that instance variable must be desig-nated Access(FIELD).* I can see a few different ways to read that: 1) @Access can be placed on the attribute to define both where to look for mapping annotations and the runtime access strategy for a given attribute. Here, we'd do: @Entity @Access(AccessType.PROPERTY) public class Course3 { @Id @GeneratedValue @Access(AccessType.FIELD) private long id; ... public long getId() { return id; } ... } 2) @Access can be placed on the attribute to define the runtime access strategy for a given attribute, but the class/hierarchy AccessType controls where to look for mapping annotations. This would lead to: @Entity @Access(AccessType.PROPERTY) public class Course3 { @Access(AccessType.FIELD) private long id; ... @Id @GeneratedValue public long getId() { return id; } ... } The test seems to illustrate that our legacy code made yet a 3rd reading of this passage such that @Access is still considered a "mapping annotation" even though that seems to directly contradict "To specify a persistent instance variable for access by the persistence provider runtime, that instance variable must be desig- nated Access(FIELD)." Is there some other passage I am missing that bears on what to do here? How do y'all feel about that passage and its implications on this test mapping? From sanne at hibernate.org Wed Mar 26 07:12:33 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Mar 2014 11:12:33 +0000 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: As a user I would not expect the @Access annotation to be treated as a special case by the framework in terms of when an annotation is ignored, as for example that I can put this on either properties or fields, and it would not be ignored, while other annotations could be ignored depending on the position. Also I highly doubt that there is a practical use case to "comment" a mapping annotation by moving it to the wrong position (say I move a @GeneratedValue from a field to a property when using FIELD access): that would be extremely confusing to maintain. The spec's wording states "When Access(PROPERTY) is applied to an [...] mapping annotations **may** be placed on .." I'd stress that it doesn' t say "must" but "may", and also doesn't seem to strictly ban the opposite. As a user if I put a mapping annotation anywhere I expect it to be respected, so I would expect the framework to work on the union of the possible positions, and probably even to throw an exception on conflicting options. The @Access property would then only be used to state which access strategy should be used (and a nice effect is tha the name becomes particularly self-explanatory too). Also there are many types of possible contradictions in the mapping options: public class Course { @Id @GeneratedValue(strategy=TABLE) private long id; ... @Id @GeneratedValue(strategy=SEQUENCE) public long getId() { return id; } Or you could have a stronger conflict which isn't solvable via AccesType "rules" either: public class Course { @Id @GeneratedValue(strategy=TABLE) @Access(AccessType.FIELD) private long id; ... @Id @GeneratedValue(strategy=SEQUENCE) @Access(AccessType.PROPERTY) public long getId() { return id; } This last example is the reason why I think you should always consistently look at both to collect mapping options, and possibly throw runtime exceptions. Sanne On 26 March 2014 04:13, Steve Ebersole wrote: > >From the test > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > we have the following: > > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > private long id; > ... > > @Id > @GeneratedValue > @Access(AccessType.FIELD) > public long getId() { > return id; > } > ... > } > > The test asserts that this is a valid mapping. Granted that the spec is > very unclear here, so I might be missing something. The pertinent spec > section here states: > > > > > > > > > > > *When Access(PROPERTY) is applied to an entity class, mapped > superclass, or embeddableclass, mapping annotations may be placed on the > properties of that class, and the persistenceprovider runtime accesses > persistent state via the properties defined by that class. All proper-ties > that are not annotated with the Transient annotation are persistent. > WhenAccess(PROPERTY) is applied to such a class, it is possible to > selectively designate indi-vidual attributes within the class for instance > variable access. To specify a persistent instancevariable for access by the > persistence provider runtime, that instance variable must be desig-nated > Access(FIELD).* > > > I can see a few different ways to read that: > > 1) @Access can be placed on the attribute to define both where to look for > mapping annotations and the runtime access strategy for a given attribute. > Here, we'd do: > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > @Id > @GeneratedValue > @Access(AccessType.FIELD) > private long id; > ... > > public long getId() { > return id; > } > ... > } > > 2) @Access can be placed on the attribute to define the runtime access > strategy for a given attribute, but the class/hierarchy AccessType controls > where to look for mapping annotations. This would lead to: > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > @Access(AccessType.FIELD) > private long id; > ... > > @Id > @GeneratedValue > public long getId() { > return id; > } > ... > } > > The test seems to illustrate that our legacy code made yet a 3rd reading of > this passage such that @Access is still considered a "mapping annotation" > even though that seems to directly contradict "To specify a persistent > instance > variable for access by the persistence provider runtime, that instance > variable must be desig- > nated Access(FIELD)." > > > Is there some other passage I am missing that bears on what to do here? > How do y'all feel about that passage and its implications on this test > mapping? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Wed Mar 26 08:55:27 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 26 Mar 2014 13:55:27 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: Message-ID: <20140326125527.GF42990@hibernate.org> I don't have a full grasp of the consequences, I'll need to think about it. Here are a few comments in the mean time. SearchFactory is not a SPI, it is used by application developers. For scalability reasons, I would be tempted to move the orm module classes out of the root package. But that is definitely the most impactful of the two moves. Emmanuel On Tue 2014-03-25 22:11, Hardy Ferentschik wrote: > Hi there, > > As part of my work for making Search OSGi ready [1], I am looking into addressing HSEARCH-1560 [2] which is about > split packages which we have between some of our Search bundles (or modules to use Maven lingo). > > Basically a split package "is caused where two or more bundles export the same package name and version, usually with different contents?. [3] > In terms of OSGi, split packages are bad and should be avoided. There exists a work around [3], but afaiu it is frowned upon. > While working on an integration test trying to run Search in Apache Karaf, I was running into this problem and basically needed (for the time being) > revert to the mentioned work around. > > The biggest for getting rid of split packages is org.hibernate.search which is a split packages between the engine and orm bundle. In org.hibernate.search of engine > we have: > - Environment, > - FullTextFilter, > - ProjectionConstants, > - SearchException, > - SearchFactory > - Version. > > org.hibernate.search of orm contains: > - FullTextQuery, > - FullTextSession, > - FullTextSharedSessionBuilder, > - MassIndexer > - Search. > > As you can see, these are quite central classes and moving any of them around will break existing code (even though updating just requires > to change import statements). If we are serious with OSGi we should address this. We always said, that Search 5 is the release where we can break > API backwards compatibility. So if we want to do this, we should do it now. On the other hand, it is a big change. > > I went ahead and tried to refactor org.hibernate.search in engine, applying the following changes: > > org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment > org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory > org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException > org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter > org.hibernate.search.Version -> org.hibernate.search.engine.Version > > Some of these changes I actually find quite fitting independently of the split package problem. FullTextFilter seems to have found its true home now > and Version and Environment don?t seem too bad either. The big change is SearchFactory and .SearchException. > > WDYT? Is this package refactoring something worth doing and if so what do you think about the new locations of the classes? Any better suggestions? > Or do you think the orm bundle should be refactored instead? > > You can see the preliminary result here [4]. > > ?Hardy > > [1] https://hibernate.atlassian.net/browse/HSEARCH-1465 > [2] https://hibernate.atlassian.net/browse/HSEARCH-1560 > [3] http://wiki.osgi.org/wiki/Split_Packages > [4] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-1560 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Wed Mar 26 09:02:16 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 26 Mar 2014 14:02:16 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: <20140326130216.GG42990@hibernate.org> My reading at the time and what I did find more intuitive is what the test represents. Entity level @AccessType expresses where the annotations should be. Otherwise the position of @Id is used to find the access type to consider annotation wise. If for a few attributes I wish to use the alternative property access, I can add @AccessType next to the other annotations but expressing that the actual property value access is based on the alternative access. That way, all annotations are in the same place. On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > As a user I would not expect the @Access annotation to be treated as a > special case by the framework in terms of when an annotation is > ignored, as for example that I can put this on either properties or > fields, and it would not be ignored, while other annotations could be > ignored depending on the position. > > Also I highly doubt that there is a practical use case to "comment" a > mapping annotation by moving it to the wrong position (say I move a > @GeneratedValue from a field to a property when using FIELD access): > that would be extremely confusing to maintain. > > The spec's wording states "When Access(PROPERTY) is applied to an > [...] mapping annotations **may** be placed on .." > I'd stress that it doesn' t say "must" but "may", and also doesn't > seem to strictly ban the opposite. > > As a user if I put a mapping annotation anywhere I expect it to be > respected, so I would expect the framework to work on the union of the > possible positions, and probably even to throw an exception on > conflicting options. The @Access property would then only be used to > state which access strategy should be used (and a nice effect is tha > the name becomes particularly self-explanatory too). > > Also there are many types of possible contradictions in the mapping options: > > public class Course { > @Id @GeneratedValue(strategy=TABLE) > private long id; > ... > > @Id @GeneratedValue(strategy=SEQUENCE) > public long getId() { > return id; > } > > Or you could have a stronger conflict which isn't solvable via > AccesType "rules" either: > > public class Course { > @Id @GeneratedValue(strategy=TABLE) > @Access(AccessType.FIELD) > private long id; > ... > > @Id @GeneratedValue(strategy=SEQUENCE) > @Access(AccessType.PROPERTY) > public long getId() { > return id; > } > > This last example is the reason why I think you should always > consistently look at both to collect mapping options, and possibly > throw runtime exceptions. > > Sanne > > > > > On 26 March 2014 04:13, Steve Ebersole wrote: > > >From the test > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > we have the following: > > > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > private long id; > > ... > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > ... > > } > > > > The test asserts that this is a valid mapping. Granted that the spec is > > very unclear here, so I might be missing something. The pertinent spec > > section here states: > > > > > > > > > > > > > > > > > > > > > > *When Access(PROPERTY) is applied to an entity class, mapped > > superclass, or embeddableclass, mapping annotations may be placed on the > > properties of that class, and the persistenceprovider runtime accesses > > persistent state via the properties defined by that class. All proper-ties > > that are not annotated with the Transient annotation are persistent. > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > > selectively designate indi-vidual attributes within the class for instance > > variable access. To specify a persistent instancevariable for access by the > > persistence provider runtime, that instance variable must be desig-nated > > Access(FIELD).* > > > > > > I can see a few different ways to read that: > > > > 1) @Access can be placed on the attribute to define both where to look for > > mapping annotations and the runtime access strategy for a given attribute. > > Here, we'd do: > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > public long getId() { > > return id; > > } > > ... > > } > > > > 2) @Access can be placed on the attribute to define the runtime access > > strategy for a given attribute, but the class/hierarchy AccessType controls > > where to look for mapping annotations. This would lead to: > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > @Id > > @GeneratedValue > > public long getId() { > > return id; > > } > > ... > > } > > > > The test seems to illustrate that our legacy code made yet a 3rd reading of > > this passage such that @Access is still considered a "mapping annotation" > > even though that seems to directly contradict "To specify a persistent > > instance > > variable for access by the persistence provider runtime, that instance > > variable must be desig- > > nated Access(FIELD)." > > > > > > Is there some other passage I am missing that bears on what to do here? > > How do y'all feel about that passage and its implications on this test > > mapping? > > _______________________________________________ > > 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 steve at hibernate.org Wed Mar 26 09:53:11 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 08:53:11 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: I think you are misreading the use of the term "may" there to mean that annotations could be placed on the field or on the getter. I read it to mean that that "may" be placed on the getter, or not (remember many attributes do not require annotations be present). I personally think it makes no sense to mix placement of annotations for a given attribute. When you say "The @Access property would then only be used to state which access strategy should be used (and a nice effect is tha the name becomes particularly self-explanatory too)", I think you are making an assumption about the meaning of the terms "access" and "access type" that the spec simply does not consistently back. In fact the very next sentence after what I quoted says (still discussing class-level Access(PROPERTY)) : "The behavior is undefined if mapping annotations are placed on any instance variables defined by the class for which Access(FIELD) is not specified". Granted the spec says the behavior is undefined, so we are free to support that if we want. However, it is clearly not the intended behavior. As I have brought up on the list a few times now recently, the notion of "access" is really 2-fold in terms of identifying: 1) where to look for annotations at binding time 2) how to extract value from and inject value into the attribute at runtime It is just so odd in retrospect that the spec never says plainly "The AccessType determined for an attribute indicates how that attribute is accessed by the persistence provider at runtime in terms of extracting and injecting values...". You make that argument, but actually the spec never says that. On Wed, Mar 26, 2014 at 6:12 AM, Sanne Grinovero wrote: > As a user I would not expect the @Access annotation to be treated as a > special case by the framework in terms of when an annotation is > ignored, as for example that I can put this on either properties or > fields, and it would not be ignored, while other annotations could be > ignored depending on the position. > > Also I highly doubt that there is a practical use case to "comment" a > mapping annotation by moving it to the wrong position (say I move a > @GeneratedValue from a field to a property when using FIELD access): > that would be extremely confusing to maintain. > > The spec's wording states "When Access(PROPERTY) is applied to an > [...] mapping annotations **may** be placed on .." > I'd stress that it doesn' t say "must" but "may", and also doesn't > seem to strictly ban the opposite. > > As a user if I put a mapping annotation anywhere I expect it to be > respected, so I would expect the framework to work on the union of the > possible positions, and probably even to throw an exception on > conflicting options. The @Access property would then only be used to > state which access strategy should be used (and a nice effect is tha > the name becomes particularly self-explanatory too). > > Also there are many types of possible contradictions in the mapping > options: > > public class Course { > @Id @GeneratedValue(strategy=TABLE) > private long id; > ... > > @Id @GeneratedValue(strategy=SEQUENCE) > public long getId() { > return id; > } > > Or you could have a stronger conflict which isn't solvable via > AccesType "rules" either: > > public class Course { > @Id @GeneratedValue(strategy=TABLE) > @Access(AccessType.FIELD) > private long id; > ... > > @Id @GeneratedValue(strategy=SEQUENCE) > @Access(AccessType.PROPERTY) > public long getId() { > return id; > } > > This last example is the reason why I think you should always > consistently look at both to collect mapping options, and possibly > throw runtime exceptions. > > Sanne > > > > > On 26 March 2014 04:13, Steve Ebersole wrote: > > >From the test > > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > we have the following: > > > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > private long id; > > ... > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > ... > > } > > > > The test asserts that this is a valid mapping. Granted that the spec is > > very unclear here, so I might be missing something. The pertinent spec > > section here states: > > > > > > > > > > > > > > > > > > > > > > *When Access(PROPERTY) is applied to an entity class, mapped > > superclass, or embeddableclass, mapping annotations may be placed on the > > properties of that class, and the persistenceprovider runtime accesses > > persistent state via the properties defined by that class. All > proper-ties > > that are not annotated with the Transient annotation are persistent. > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > > selectively designate indi-vidual attributes within the class for > instance > > variable access. To specify a persistent instancevariable for access by > the > > persistence provider runtime, that instance variable must be desig-nated > > Access(FIELD).* > > > > > > I can see a few different ways to read that: > > > > 1) @Access can be placed on the attribute to define both where to look > for > > mapping annotations and the runtime access strategy for a given > attribute. > > Here, we'd do: > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > public long getId() { > > return id; > > } > > ... > > } > > > > 2) @Access can be placed on the attribute to define the runtime access > > strategy for a given attribute, but the class/hierarchy AccessType > controls > > where to look for mapping annotations. This would lead to: > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > @Id > > @GeneratedValue > > public long getId() { > > return id; > > } > > ... > > } > > > > The test seems to illustrate that our legacy code made yet a 3rd reading > of > > this passage such that @Access is still considered a "mapping annotation" > > even though that seems to directly contradict "To specify a persistent > > instance > > variable for access by the persistence provider runtime, that instance > > variable must be desig- > > nated Access(FIELD)." > > > > > > Is there some other passage I am missing that bears on what to do here? > > How do y'all feel about that passage and its implications on this test > > mapping? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Mar 26 09:57:24 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 08:57:24 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <20140326130216.GG42990@hibernate.org> References: <20140326130216.GG42990@hibernate.org> Message-ID: Again from the spec (still discussing class-level Access(PROPERTY)) : "The behavior is undefined if mapping annotations are placed on any instance variables defined by the class for which Access(FIELD) is not specified". Which to me implies that the expectation for switching access for a particular field within such a class is to annotate the *field* with Access(FIELD). Also the footnote to this sections seems very relevant: "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)..." On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard wrote: > My reading at the time and what I did find more intuitive is what the > test represents. > > Entity level @AccessType expresses where the annotations should > be. Otherwise the position of @Id is used to find the access type to > consider annotation wise. > > If for a few attributes I wish to use the alternative property access, I > can add @AccessType next to the other annotations but expressing that > the actual property value access is based on the alternative access. > That way, all annotations are in the same place. > > On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > > As a user I would not expect the @Access annotation to be treated as a > > special case by the framework in terms of when an annotation is > > ignored, as for example that I can put this on either properties or > > fields, and it would not be ignored, while other annotations could be > > ignored depending on the position. > > > > Also I highly doubt that there is a practical use case to "comment" a > > mapping annotation by moving it to the wrong position (say I move a > > @GeneratedValue from a field to a property when using FIELD access): > > that would be extremely confusing to maintain. > > > > The spec's wording states "When Access(PROPERTY) is applied to an > > [...] mapping annotations **may** be placed on .." > > I'd stress that it doesn' t say "must" but "may", and also doesn't > > seem to strictly ban the opposite. > > > > As a user if I put a mapping annotation anywhere I expect it to be > > respected, so I would expect the framework to work on the union of the > > possible positions, and probably even to throw an exception on > > conflicting options. The @Access property would then only be used to > > state which access strategy should be used (and a nice effect is tha > > the name becomes particularly self-explanatory too). > > > > Also there are many types of possible contradictions in the mapping > options: > > > > public class Course { > > @Id @GeneratedValue(strategy=TABLE) > > private long id; > > ... > > > > @Id @GeneratedValue(strategy=SEQUENCE) > > public long getId() { > > return id; > > } > > > > Or you could have a stronger conflict which isn't solvable via > > AccesType "rules" either: > > > > public class Course { > > @Id @GeneratedValue(strategy=TABLE) > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > @Id @GeneratedValue(strategy=SEQUENCE) > > @Access(AccessType.PROPERTY) > > public long getId() { > > return id; > > } > > > > This last example is the reason why I think you should always > > consistently look at both to collect mapping options, and possibly > > throw runtime exceptions. > > > > Sanne > > > > > > > > > > On 26 March 2014 04:13, Steve Ebersole wrote: > > > >From the test > > > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > > we have the following: > > > > > > > > > @Entity > > > @Access(AccessType.PROPERTY) > > > public class Course3 { > > > private long id; > > > ... > > > > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > public long getId() { > > > return id; > > > } > > > ... > > > } > > > > > > The test asserts that this is a valid mapping. Granted that the spec > is > > > very unclear here, so I might be missing something. The pertinent spec > > > section here states: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *When Access(PROPERTY) is applied to an entity class, mapped > > > superclass, or embeddableclass, mapping annotations may be placed on > the > > > properties of that class, and the persistenceprovider runtime accesses > > > persistent state via the properties defined by that class. All > proper-ties > > > that are not annotated with the Transient annotation are persistent. > > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > > > selectively designate indi-vidual attributes within the class for > instance > > > variable access. To specify a persistent instancevariable for access > by the > > > persistence provider runtime, that instance variable must be > desig-nated > > > Access(FIELD).* > > > > > > > > > I can see a few different ways to read that: > > > > > > 1) @Access can be placed on the attribute to define both where to look > for > > > mapping annotations and the runtime access strategy for a given > attribute. > > > Here, we'd do: > > > > > > @Entity > > > @Access(AccessType.PROPERTY) > > > public class Course3 { > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > private long id; > > > ... > > > > > > public long getId() { > > > return id; > > > } > > > ... > > > } > > > > > > 2) @Access can be placed on the attribute to define the runtime access > > > strategy for a given attribute, but the class/hierarchy AccessType > controls > > > where to look for mapping annotations. This would lead to: > > > > > > @Entity > > > @Access(AccessType.PROPERTY) > > > public class Course3 { > > > @Access(AccessType.FIELD) > > > private long id; > > > ... > > > > > > @Id > > > @GeneratedValue > > > public long getId() { > > > return id; > > > } > > > ... > > > } > > > > > > The test seems to illustrate that our legacy code made yet a 3rd > reading of > > > this passage such that @Access is still considered a "mapping > annotation" > > > even though that seems to directly contradict "To specify a persistent > > > instance > > > variable for access by the persistence provider runtime, that instance > > > variable must be desig- > > > nated Access(FIELD)." > > > > > > > > > Is there some other passage I am missing that bears on what to do here? > > > How do y'all feel about that passage and its implications on this test > > > mapping? > > > _______________________________________________ > > > 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 Wed Mar 26 10:56:44 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Mar 2014 14:56:44 +0000 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> Message-ID: I do of course agree that people should use a single strategy and stick to it, so I agree with your reading about what the "general expectation" is. But the original test represents a quite naturally looking example and it's hard to justify why that should be considered illegal; I'd probably be more inclined in making user's life easier than try to lecture them about how a proper mapping should look like. Ignoring any annotation leads to waste of time and debugging frustration, so rather than silently discarding a mis-positioned annotation I'd prefer a fail-fast approach; that said I think just applying them all - as long as there are no obvious conflicting annotations - would be even more user friendly and doesn't seem to violate any specific wording of the spec. Sanne On 26 March 2014 13:57, Steve Ebersole wrote: > Again from the spec (still discussing class-level Access(PROPERTY)) : "The > behavior is undefined if mapping annotations are placed on any instance > variables defined by the class for which Access(FIELD) is not specified". > > Which to me implies that the expectation for switching access for a > particular field within such a class is to annotate the *field* with > Access(FIELD). > > Also the footnote to this sections seems very relevant: > > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a > property as Access(FIELD)..." > > > > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard > wrote: >> >> My reading at the time and what I did find more intuitive is what the >> test represents. >> >> Entity level @AccessType expresses where the annotations should >> be. Otherwise the position of @Id is used to find the access type to >> consider annotation wise. >> >> If for a few attributes I wish to use the alternative property access, I >> can add @AccessType next to the other annotations but expressing that >> the actual property value access is based on the alternative access. >> That way, all annotations are in the same place. >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: >> > As a user I would not expect the @Access annotation to be treated as a >> > special case by the framework in terms of when an annotation is >> > ignored, as for example that I can put this on either properties or >> > fields, and it would not be ignored, while other annotations could be >> > ignored depending on the position. >> > >> > Also I highly doubt that there is a practical use case to "comment" a >> > mapping annotation by moving it to the wrong position (say I move a >> > @GeneratedValue from a field to a property when using FIELD access): >> > that would be extremely confusing to maintain. >> > >> > The spec's wording states "When Access(PROPERTY) is applied to an >> > [...] mapping annotations **may** be placed on .." >> > I'd stress that it doesn' t say "must" but "may", and also doesn't >> > seem to strictly ban the opposite. >> > >> > As a user if I put a mapping annotation anywhere I expect it to be >> > respected, so I would expect the framework to work on the union of the >> > possible positions, and probably even to throw an exception on >> > conflicting options. The @Access property would then only be used to >> > state which access strategy should be used (and a nice effect is tha >> > the name becomes particularly self-explanatory too). >> > >> > Also there are many types of possible contradictions in the mapping >> > options: >> > >> > public class Course { >> > @Id @GeneratedValue(strategy=TABLE) >> > private long id; >> > ... >> > >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > public long getId() { >> > return id; >> > } >> > >> > Or you could have a stronger conflict which isn't solvable via >> > AccesType "rules" either: >> > >> > public class Course { >> > @Id @GeneratedValue(strategy=TABLE) >> > @Access(AccessType.FIELD) >> > private long id; >> > ... >> > >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > @Access(AccessType.PROPERTY) >> > public long getId() { >> > return id; >> > } >> > >> > This last example is the reason why I think you should always >> > consistently look at both to collect mapping options, and possibly >> > throw runtime exceptions. >> > >> > Sanne >> > >> > >> > >> > >> > On 26 March 2014 04:13, Steve Ebersole wrote: >> > > >From the test >> > > >> > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride >> > > we have the following: >> > > >> > > >> > > @Entity >> > > @Access(AccessType.PROPERTY) >> > > public class Course3 { >> > > private long id; >> > > ... >> > > >> > > @Id >> > > @GeneratedValue >> > > @Access(AccessType.FIELD) >> > > public long getId() { >> > > return id; >> > > } >> > > ... >> > > } >> > > >> > > The test asserts that this is a valid mapping. Granted that the spec >> > > is >> > > very unclear here, so I might be missing something. The pertinent >> > > spec >> > > section here states: >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > *When Access(PROPERTY) is applied to an entity class, mapped >> > > superclass, or embeddableclass, mapping annotations may be placed on >> > > the >> > > properties of that class, and the persistenceprovider runtime accesses >> > > persistent state via the properties defined by that class. All >> > > proper-ties >> > > that are not annotated with the Transient annotation are persistent. >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to >> > > selectively designate indi-vidual attributes within the class for >> > > instance >> > > variable access. To specify a persistent instancevariable for access >> > > by the >> > > persistence provider runtime, that instance variable must be >> > > desig-nated >> > > Access(FIELD).* >> > > >> > > >> > > I can see a few different ways to read that: >> > > >> > > 1) @Access can be placed on the attribute to define both where to look >> > > for >> > > mapping annotations and the runtime access strategy for a given >> > > attribute. >> > > Here, we'd do: >> > > >> > > @Entity >> > > @Access(AccessType.PROPERTY) >> > > public class Course3 { >> > > @Id >> > > @GeneratedValue >> > > @Access(AccessType.FIELD) >> > > private long id; >> > > ... >> > > >> > > public long getId() { >> > > return id; >> > > } >> > > ... >> > > } >> > > >> > > 2) @Access can be placed on the attribute to define the runtime access >> > > strategy for a given attribute, but the class/hierarchy AccessType >> > > controls >> > > where to look for mapping annotations. This would lead to: >> > > >> > > @Entity >> > > @Access(AccessType.PROPERTY) >> > > public class Course3 { >> > > @Access(AccessType.FIELD) >> > > private long id; >> > > ... >> > > >> > > @Id >> > > @GeneratedValue >> > > public long getId() { >> > > return id; >> > > } >> > > ... >> > > } >> > > >> > > The test seems to illustrate that our legacy code made yet a 3rd >> > > reading of >> > > this passage such that @Access is still considered a "mapping >> > > annotation" >> > > even though that seems to directly contradict "To specify a persistent >> > > instance >> > > variable for access by the persistence provider runtime, that instance >> > > variable must be desig- >> > > nated Access(FIELD)." >> > > >> > > >> > > Is there some other passage I am missing that bears on what to do >> > > here? >> > > How do y'all feel about that passage and its implications on this >> > > test >> > > mapping? >> > > _______________________________________________ >> > > 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 steve at hibernate.org Wed Mar 26 11:12:40 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 10:12:40 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> Message-ID: It does violate the spec though, that's the problem: "... It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)..." which imo is exactly what this is doing (specifying a property as FIELD): @Id @GeneratedValue @Access(AccessType.FIELD) public long getId() { return id; } On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero wrote: > I do of course agree that people should use a single strategy and > stick to it, so I agree with your reading about what the "general > expectation" is. > > But the original test represents a quite naturally looking example and > it's hard to justify why that should be considered illegal; I'd > probably be more inclined in making user's life easier than try to > lecture them about how a proper mapping should look like. > > Ignoring any annotation leads to waste of time and debugging > frustration, so rather than silently discarding a mis-positioned > annotation I'd prefer a fail-fast approach; that said I think just > applying them all - as long as there are no obvious conflicting > annotations - would be even more user friendly and doesn't seem to > violate any specific wording of the spec. > > Sanne > > > On 26 March 2014 13:57, Steve Ebersole wrote: > > Again from the spec (still discussing class-level Access(PROPERTY)) : > "The > > behavior is undefined if mapping annotations are placed on any instance > > variables defined by the class for which Access(FIELD) is not specified". > > > > Which to me implies that the expectation for switching access for a > > particular field within such a class is to annotate the *field* with > > Access(FIELD). > > > > Also the footnote to this sections seems very relevant: > > > > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a > > property as Access(FIELD)..." > > > > > > > > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > emmanuel at hibernate.org> > > wrote: > >> > >> My reading at the time and what I did find more intuitive is what the > >> test represents. > >> > >> Entity level @AccessType expresses where the annotations should > >> be. Otherwise the position of @Id is used to find the access type to > >> consider annotation wise. > >> > >> If for a few attributes I wish to use the alternative property access, I > >> can add @AccessType next to the other annotations but expressing that > >> the actual property value access is based on the alternative access. > >> That way, all annotations are in the same place. > >> > >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > >> > As a user I would not expect the @Access annotation to be treated as a > >> > special case by the framework in terms of when an annotation is > >> > ignored, as for example that I can put this on either properties or > >> > fields, and it would not be ignored, while other annotations could be > >> > ignored depending on the position. > >> > > >> > Also I highly doubt that there is a practical use case to "comment" a > >> > mapping annotation by moving it to the wrong position (say I move a > >> > @GeneratedValue from a field to a property when using FIELD access): > >> > that would be extremely confusing to maintain. > >> > > >> > The spec's wording states "When Access(PROPERTY) is applied to an > >> > [...] mapping annotations **may** be placed on .." > >> > I'd stress that it doesn' t say "must" but "may", and also doesn't > >> > seem to strictly ban the opposite. > >> > > >> > As a user if I put a mapping annotation anywhere I expect it to be > >> > respected, so I would expect the framework to work on the union of the > >> > possible positions, and probably even to throw an exception on > >> > conflicting options. The @Access property would then only be used to > >> > state which access strategy should be used (and a nice effect is tha > >> > the name becomes particularly self-explanatory too). > >> > > >> > Also there are many types of possible contradictions in the mapping > >> > options: > >> > > >> > public class Course { > >> > @Id @GeneratedValue(strategy=TABLE) > >> > private long id; > >> > ... > >> > > >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > public long getId() { > >> > return id; > >> > } > >> > > >> > Or you could have a stronger conflict which isn't solvable via > >> > AccesType "rules" either: > >> > > >> > public class Course { > >> > @Id @GeneratedValue(strategy=TABLE) > >> > @Access(AccessType.FIELD) > >> > private long id; > >> > ... > >> > > >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > @Access(AccessType.PROPERTY) > >> > public long getId() { > >> > return id; > >> > } > >> > > >> > This last example is the reason why I think you should always > >> > consistently look at both to collect mapping options, and possibly > >> > throw runtime exceptions. > >> > > >> > Sanne > >> > > >> > > >> > > >> > > >> > On 26 March 2014 04:13, Steve Ebersole wrote: > >> > > >From the test > >> > > > >> > > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > >> > > we have the following: > >> > > > >> > > > >> > > @Entity > >> > > @Access(AccessType.PROPERTY) > >> > > public class Course3 { > >> > > private long id; > >> > > ... > >> > > > >> > > @Id > >> > > @GeneratedValue > >> > > @Access(AccessType.FIELD) > >> > > public long getId() { > >> > > return id; > >> > > } > >> > > ... > >> > > } > >> > > > >> > > The test asserts that this is a valid mapping. Granted that the > spec > >> > > is > >> > > very unclear here, so I might be missing something. The pertinent > >> > > spec > >> > > section here states: > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > *When Access(PROPERTY) is applied to an entity class, mapped > >> > > superclass, or embeddableclass, mapping annotations may be placed on > >> > > the > >> > > properties of that class, and the persistenceprovider runtime > accesses > >> > > persistent state via the properties defined by that class. All > >> > > proper-ties > >> > > that are not annotated with the Transient annotation are persistent. > >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > >> > > selectively designate indi-vidual attributes within the class for > >> > > instance > >> > > variable access. To specify a persistent instancevariable for access > >> > > by the > >> > > persistence provider runtime, that instance variable must be > >> > > desig-nated > >> > > Access(FIELD).* > >> > > > >> > > > >> > > I can see a few different ways to read that: > >> > > > >> > > 1) @Access can be placed on the attribute to define both where to > look > >> > > for > >> > > mapping annotations and the runtime access strategy for a given > >> > > attribute. > >> > > Here, we'd do: > >> > > > >> > > @Entity > >> > > @Access(AccessType.PROPERTY) > >> > > public class Course3 { > >> > > @Id > >> > > @GeneratedValue > >> > > @Access(AccessType.FIELD) > >> > > private long id; > >> > > ... > >> > > > >> > > public long getId() { > >> > > return id; > >> > > } > >> > > ... > >> > > } > >> > > > >> > > 2) @Access can be placed on the attribute to define the runtime > access > >> > > strategy for a given attribute, but the class/hierarchy AccessType > >> > > controls > >> > > where to look for mapping annotations. This would lead to: > >> > > > >> > > @Entity > >> > > @Access(AccessType.PROPERTY) > >> > > public class Course3 { > >> > > @Access(AccessType.FIELD) > >> > > private long id; > >> > > ... > >> > > > >> > > @Id > >> > > @GeneratedValue > >> > > public long getId() { > >> > > return id; > >> > > } > >> > > ... > >> > > } > >> > > > >> > > The test seems to illustrate that our legacy code made yet a 3rd > >> > > reading of > >> > > this passage such that @Access is still considered a "mapping > >> > > annotation" > >> > > even though that seems to directly contradict "To specify a > persistent > >> > > instance > >> > > variable for access by the persistence provider runtime, that > instance > >> > > variable must be desig- > >> > > nated Access(FIELD)." > >> > > > >> > > > >> > > Is there some other passage I am missing that bears on what to do > >> > > here? > >> > > How do y'all feel about that passage and its implications on this > >> > > test > >> > > mapping? > >> > > _______________________________________________ > >> > > 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 steve at hibernate.org Wed Mar 26 12:14:06 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 11:14:06 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> Message-ID: On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole wrote: > It does violate the spec though, that's the problem: > Well it *could* be read to violate the spec. That's inherently the problem with specs that use unclear wording; they can be read and argued multiple ways. > > "... It is not permitted to specify a field as Access(PROPERTY) or a > property as Access(FIELD)..." > > which imo is exactly what this is doing (specifying a property as FIELD): > > @Id > @GeneratedValue > @Access(AccessType.FIELD) > public long getId() { > return id; > } > > > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero wrote: > >> I do of course agree that people should use a single strategy and >> stick to it, so I agree with your reading about what the "general >> expectation" is. >> >> But the original test represents a quite naturally looking example and >> it's hard to justify why that should be considered illegal; I'd >> probably be more inclined in making user's life easier than try to >> lecture them about how a proper mapping should look like. >> >> Ignoring any annotation leads to waste of time and debugging >> frustration, so rather than silently discarding a mis-positioned >> annotation I'd prefer a fail-fast approach; that said I think just >> applying them all - as long as there are no obvious conflicting >> annotations - would be even more user friendly and doesn't seem to >> violate any specific wording of the spec. >> >> Sanne >> >> >> On 26 March 2014 13:57, Steve Ebersole wrote: >> > Again from the spec (still discussing class-level Access(PROPERTY)) : >> "The >> > behavior is undefined if mapping annotations are placed on any instance >> > variables defined by the class for which Access(FIELD) is not >> specified". >> > >> > Which to me implies that the expectation for switching access for a >> > particular field within such a class is to annotate the *field* with >> > Access(FIELD). >> > >> > Also the footnote to this sections seems very relevant: >> > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a >> > property as Access(FIELD)..." >> > >> > >> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < >> emmanuel at hibernate.org> >> > wrote: >> >> >> >> My reading at the time and what I did find more intuitive is what the >> >> test represents. >> >> >> >> Entity level @AccessType expresses where the annotations should >> >> be. Otherwise the position of @Id is used to find the access type to >> >> consider annotation wise. >> >> >> >> If for a few attributes I wish to use the alternative property access, >> I >> >> can add @AccessType next to the other annotations but expressing that >> >> the actual property value access is based on the alternative access. >> >> That way, all annotations are in the same place. >> >> >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: >> >> > As a user I would not expect the @Access annotation to be treated as >> a >> >> > special case by the framework in terms of when an annotation is >> >> > ignored, as for example that I can put this on either properties or >> >> > fields, and it would not be ignored, while other annotations could be >> >> > ignored depending on the position. >> >> > >> >> > Also I highly doubt that there is a practical use case to "comment" a >> >> > mapping annotation by moving it to the wrong position (say I move a >> >> > @GeneratedValue from a field to a property when using FIELD access): >> >> > that would be extremely confusing to maintain. >> >> > >> >> > The spec's wording states "When Access(PROPERTY) is applied to an >> >> > [...] mapping annotations **may** be placed on .." >> >> > I'd stress that it doesn' t say "must" but "may", and also doesn't >> >> > seem to strictly ban the opposite. >> >> > >> >> > As a user if I put a mapping annotation anywhere I expect it to be >> >> > respected, so I would expect the framework to work on the union of >> the >> >> > possible positions, and probably even to throw an exception on >> >> > conflicting options. The @Access property would then only be used to >> >> > state which access strategy should be used (and a nice effect is tha >> >> > the name becomes particularly self-explanatory too). >> >> > >> >> > Also there are many types of possible contradictions in the mapping >> >> > options: >> >> > >> >> > public class Course { >> >> > @Id @GeneratedValue(strategy=TABLE) >> >> > private long id; >> >> > ... >> >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> >> > public long getId() { >> >> > return id; >> >> > } >> >> > >> >> > Or you could have a stronger conflict which isn't solvable via >> >> > AccesType "rules" either: >> >> > >> >> > public class Course { >> >> > @Id @GeneratedValue(strategy=TABLE) >> >> > @Access(AccessType.FIELD) >> >> > private long id; >> >> > ... >> >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> >> > @Access(AccessType.PROPERTY) >> >> > public long getId() { >> >> > return id; >> >> > } >> >> > >> >> > This last example is the reason why I think you should always >> >> > consistently look at both to collect mapping options, and possibly >> >> > throw runtime exceptions. >> >> > >> >> > Sanne >> >> > >> >> > >> >> > >> >> > >> >> > On 26 March 2014 04:13, Steve Ebersole wrote: >> >> > > >From the test >> >> > > >> >> > > >> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride >> >> > > we have the following: >> >> > > >> >> > > >> >> > > @Entity >> >> > > @Access(AccessType.PROPERTY) >> >> > > public class Course3 { >> >> > > private long id; >> >> > > ... >> >> > > >> >> > > @Id >> >> > > @GeneratedValue >> >> > > @Access(AccessType.FIELD) >> >> > > public long getId() { >> >> > > return id; >> >> > > } >> >> > > ... >> >> > > } >> >> > > >> >> > > The test asserts that this is a valid mapping. Granted that the >> spec >> >> > > is >> >> > > very unclear here, so I might be missing something. The pertinent >> >> > > spec >> >> > > section here states: >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > *When Access(PROPERTY) is applied to an entity class, mapped >> >> > > superclass, or embeddableclass, mapping annotations may be placed >> on >> >> > > the >> >> > > properties of that class, and the persistenceprovider runtime >> accesses >> >> > > persistent state via the properties defined by that class. All >> >> > > proper-ties >> >> > > that are not annotated with the Transient annotation are >> persistent. >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to >> >> > > selectively designate indi-vidual attributes within the class for >> >> > > instance >> >> > > variable access. To specify a persistent instancevariable for >> access >> >> > > by the >> >> > > persistence provider runtime, that instance variable must be >> >> > > desig-nated >> >> > > Access(FIELD).* >> >> > > >> >> > > >> >> > > I can see a few different ways to read that: >> >> > > >> >> > > 1) @Access can be placed on the attribute to define both where to >> look >> >> > > for >> >> > > mapping annotations and the runtime access strategy for a given >> >> > > attribute. >> >> > > Here, we'd do: >> >> > > >> >> > > @Entity >> >> > > @Access(AccessType.PROPERTY) >> >> > > public class Course3 { >> >> > > @Id >> >> > > @GeneratedValue >> >> > > @Access(AccessType.FIELD) >> >> > > private long id; >> >> > > ... >> >> > > >> >> > > public long getId() { >> >> > > return id; >> >> > > } >> >> > > ... >> >> > > } >> >> > > >> >> > > 2) @Access can be placed on the attribute to define the runtime >> access >> >> > > strategy for a given attribute, but the class/hierarchy AccessType >> >> > > controls >> >> > > where to look for mapping annotations. This would lead to: >> >> > > >> >> > > @Entity >> >> > > @Access(AccessType.PROPERTY) >> >> > > public class Course3 { >> >> > > @Access(AccessType.FIELD) >> >> > > private long id; >> >> > > ... >> >> > > >> >> > > @Id >> >> > > @GeneratedValue >> >> > > public long getId() { >> >> > > return id; >> >> > > } >> >> > > ... >> >> > > } >> >> > > >> >> > > The test seems to illustrate that our legacy code made yet a 3rd >> >> > > reading of >> >> > > this passage such that @Access is still considered a "mapping >> >> > > annotation" >> >> > > even though that seems to directly contradict "To specify a >> persistent >> >> > > instance >> >> > > variable for access by the persistence provider runtime, that >> instance >> >> > > variable must be desig- >> >> > > nated Access(FIELD)." >> >> > > >> >> > > >> >> > > Is there some other passage I am missing that bears on what to do >> >> > > here? >> >> > > How do y'all feel about that passage and its implications on this >> >> > > test >> >> > > mapping? >> >> > > _______________________________________________ >> >> > > 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 emmanuel at hibernate.org Wed Mar 26 12:21:59 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 26 Mar 2014 17:21:59 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> Message-ID: <20140326162159.GK42990@hibernate.org> My take on the spec as always been that I'd rather follow the intent, the common sense above the letter. Likewise, I favored user experience over spec strict adherence. I did clash numerous time with the TCK in these targets but I still prefer that over just doing something stupid but spec to the letter. (this is general and not specific to that case). Anyway so my take is pretty much as it was when I first implemented @AccessType even if it steps over the spec at the margin. BTW I'm also happy if we all decide I made a usability mistake that should be fixed. Emmanuel On Wed 2014-03-26 11:14, Steve Ebersole wrote: > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole wrote: > > > It does violate the spec though, that's the problem: > > > > Well it *could* be read to violate the spec. That's inherently the problem > with specs that use unclear wording; they can be read and argued multiple > ways. > > > > > > > "... It is not permitted to specify a field as Access(PROPERTY) or a > > property as Access(FIELD)..." > > > > which imo is exactly what this is doing (specifying a property as FIELD): > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > > > > > > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero wrote: > > > >> I do of course agree that people should use a single strategy and > >> stick to it, so I agree with your reading about what the "general > >> expectation" is. > >> > >> But the original test represents a quite naturally looking example and > >> it's hard to justify why that should be considered illegal; I'd > >> probably be more inclined in making user's life easier than try to > >> lecture them about how a proper mapping should look like. > >> > >> Ignoring any annotation leads to waste of time and debugging > >> frustration, so rather than silently discarding a mis-positioned > >> annotation I'd prefer a fail-fast approach; that said I think just > >> applying them all - as long as there are no obvious conflicting > >> annotations - would be even more user friendly and doesn't seem to > >> violate any specific wording of the spec. > >> > >> Sanne > >> > >> > >> On 26 March 2014 13:57, Steve Ebersole wrote: > >> > Again from the spec (still discussing class-level Access(PROPERTY)) : > >> "The > >> > behavior is undefined if mapping annotations are placed on any instance > >> > variables defined by the class for which Access(FIELD) is not > >> specified". > >> > > >> > Which to me implies that the expectation for switching access for a > >> > particular field within such a class is to annotate the *field* with > >> > Access(FIELD). > >> > > >> > Also the footnote to this sections seems very relevant: > >> > > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a > >> > property as Access(FIELD)..." > >> > > >> > > >> > > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > >> emmanuel at hibernate.org> > >> > wrote: > >> >> > >> >> My reading at the time and what I did find more intuitive is what the > >> >> test represents. > >> >> > >> >> Entity level @AccessType expresses where the annotations should > >> >> be. Otherwise the position of @Id is used to find the access type to > >> >> consider annotation wise. > >> >> > >> >> If for a few attributes I wish to use the alternative property access, > >> I > >> >> can add @AccessType next to the other annotations but expressing that > >> >> the actual property value access is based on the alternative access. > >> >> That way, all annotations are in the same place. > >> >> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > >> >> > As a user I would not expect the @Access annotation to be treated as > >> a > >> >> > special case by the framework in terms of when an annotation is > >> >> > ignored, as for example that I can put this on either properties or > >> >> > fields, and it would not be ignored, while other annotations could be > >> >> > ignored depending on the position. > >> >> > > >> >> > Also I highly doubt that there is a practical use case to "comment" a > >> >> > mapping annotation by moving it to the wrong position (say I move a > >> >> > @GeneratedValue from a field to a property when using FIELD access): > >> >> > that would be extremely confusing to maintain. > >> >> > > >> >> > The spec's wording states "When Access(PROPERTY) is applied to an > >> >> > [...] mapping annotations **may** be placed on .." > >> >> > I'd stress that it doesn' t say "must" but "may", and also doesn't > >> >> > seem to strictly ban the opposite. > >> >> > > >> >> > As a user if I put a mapping annotation anywhere I expect it to be > >> >> > respected, so I would expect the framework to work on the union of > >> the > >> >> > possible positions, and probably even to throw an exception on > >> >> > conflicting options. The @Access property would then only be used to > >> >> > state which access strategy should be used (and a nice effect is tha > >> >> > the name becomes particularly self-explanatory too). > >> >> > > >> >> > Also there are many types of possible contradictions in the mapping > >> >> > options: > >> >> > > >> >> > public class Course { > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> >> > private long id; > >> >> > ... > >> >> > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> >> > public long getId() { > >> >> > return id; > >> >> > } > >> >> > > >> >> > Or you could have a stronger conflict which isn't solvable via > >> >> > AccesType "rules" either: > >> >> > > >> >> > public class Course { > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> >> > @Access(AccessType.FIELD) > >> >> > private long id; > >> >> > ... > >> >> > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> >> > @Access(AccessType.PROPERTY) > >> >> > public long getId() { > >> >> > return id; > >> >> > } > >> >> > > >> >> > This last example is the reason why I think you should always > >> >> > consistently look at both to collect mapping options, and possibly > >> >> > throw runtime exceptions. > >> >> > > >> >> > Sanne > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On 26 March 2014 04:13, Steve Ebersole wrote: > >> >> > > >From the test > >> >> > > > >> >> > > > >> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > >> >> > > we have the following: > >> >> > > > >> >> > > > >> >> > > @Entity > >> >> > > @Access(AccessType.PROPERTY) > >> >> > > public class Course3 { > >> >> > > private long id; > >> >> > > ... > >> >> > > > >> >> > > @Id > >> >> > > @GeneratedValue > >> >> > > @Access(AccessType.FIELD) > >> >> > > public long getId() { > >> >> > > return id; > >> >> > > } > >> >> > > ... > >> >> > > } > >> >> > > > >> >> > > The test asserts that this is a valid mapping. Granted that the > >> spec > >> >> > > is > >> >> > > very unclear here, so I might be missing something. The pertinent > >> >> > > spec > >> >> > > section here states: > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > *When Access(PROPERTY) is applied to an entity class, mapped > >> >> > > superclass, or embeddableclass, mapping annotations may be placed > >> on > >> >> > > the > >> >> > > properties of that class, and the persistenceprovider runtime > >> accesses > >> >> > > persistent state via the properties defined by that class. All > >> >> > > proper-ties > >> >> > > that are not annotated with the Transient annotation are > >> persistent. > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > >> >> > > selectively designate indi-vidual attributes within the class for > >> >> > > instance > >> >> > > variable access. To specify a persistent instancevariable for > >> access > >> >> > > by the > >> >> > > persistence provider runtime, that instance variable must be > >> >> > > desig-nated > >> >> > > Access(FIELD).* > >> >> > > > >> >> > > > >> >> > > I can see a few different ways to read that: > >> >> > > > >> >> > > 1) @Access can be placed on the attribute to define both where to > >> look > >> >> > > for > >> >> > > mapping annotations and the runtime access strategy for a given > >> >> > > attribute. > >> >> > > Here, we'd do: > >> >> > > > >> >> > > @Entity > >> >> > > @Access(AccessType.PROPERTY) > >> >> > > public class Course3 { > >> >> > > @Id > >> >> > > @GeneratedValue > >> >> > > @Access(AccessType.FIELD) > >> >> > > private long id; > >> >> > > ... > >> >> > > > >> >> > > public long getId() { > >> >> > > return id; > >> >> > > } > >> >> > > ... > >> >> > > } > >> >> > > > >> >> > > 2) @Access can be placed on the attribute to define the runtime > >> access > >> >> > > strategy for a given attribute, but the class/hierarchy AccessType > >> >> > > controls > >> >> > > where to look for mapping annotations. This would lead to: > >> >> > > > >> >> > > @Entity > >> >> > > @Access(AccessType.PROPERTY) > >> >> > > public class Course3 { > >> >> > > @Access(AccessType.FIELD) > >> >> > > private long id; > >> >> > > ... > >> >> > > > >> >> > > @Id > >> >> > > @GeneratedValue > >> >> > > public long getId() { > >> >> > > return id; > >> >> > > } > >> >> > > ... > >> >> > > } > >> >> > > > >> >> > > The test seems to illustrate that our legacy code made yet a 3rd > >> >> > > reading of > >> >> > > this passage such that @Access is still considered a "mapping > >> >> > > annotation" > >> >> > > even though that seems to directly contradict "To specify a > >> persistent > >> >> > > instance > >> >> > > variable for access by the persistence provider runtime, that > >> instance > >> >> > > variable must be desig- > >> >> > > nated Access(FIELD)." > >> >> > > > >> >> > > > >> >> > > Is there some other passage I am missing that bears on what to do > >> >> > > here? > >> >> > > How do y'all feel about that passage and its implications on this > >> >> > > test > >> >> > > mapping? > >> >> > > _______________________________________________ > >> >> > > 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 steve at hibernate.org Wed Mar 26 14:37:23 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 13:37:23 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <20140326162159.GK42990@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: My point is that I do not find annotating a getter method with @Access(FIELD) to be inherently common sense. It really boils down to the purpose/intent of @Access. If @Access *at the attribute level* is ultimately *just* indicating how to extract/inject then I think @Access(FIELD) on the getter does make sense. If @Access *at the attribute level* also directs where to look for annotations (consistent with @Access at class/hierarchy-level) then I think @AccessFile needs to be on the field along with the other annotations, assuming we stay with non-mixed placement for an attribute. So let's decide that first. Since the spec does not say clearly one way or the other, I guess we have some leeway here. https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and @IdSetter) plays in here as well. On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard wrote: > My take on the spec as always been that I'd rather follow the intent, > the common sense above the letter. Likewise, I favored user experience > over spec strict adherence. > I did clash numerous time with the TCK in these targets but I still > prefer that over just doing something stupid but spec to the letter. > (this is general and not specific to that case). > > Anyway so my take is pretty much as it was when I first implemented > @AccessType even if it steps over the spec at the margin. > BTW I'm also happy if we all decide I made a usability mistake that should > be fixed. > > Emmanuel > > On Wed 2014-03-26 11:14, Steve Ebersole wrote: > > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole >wrote: > > > > > It does violate the spec though, that's the problem: > > > > > > > Well it *could* be read to violate the spec. That's inherently the > problem > > with specs that use unclear wording; they can be read and argued multiple > > ways. > > > > > > > > > > > > "... It is not permitted to specify a field as Access(PROPERTY) or a > > > property as Access(FIELD)..." > > > > > > which imo is exactly what this is doing (specifying a property as > FIELD): > > > > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > public long getId() { > > > return id; > > > } > > > > > > > > > > > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero >wrote: > > > > > >> I do of course agree that people should use a single strategy and > > >> stick to it, so I agree with your reading about what the "general > > >> expectation" is. > > >> > > >> But the original test represents a quite naturally looking example and > > >> it's hard to justify why that should be considered illegal; I'd > > >> probably be more inclined in making user's life easier than try to > > >> lecture them about how a proper mapping should look like. > > >> > > >> Ignoring any annotation leads to waste of time and debugging > > >> frustration, so rather than silently discarding a mis-positioned > > >> annotation I'd prefer a fail-fast approach; that said I think just > > >> applying them all - as long as there are no obvious conflicting > > >> annotations - would be even more user friendly and doesn't seem to > > >> violate any specific wording of the spec. > > >> > > >> Sanne > > >> > > >> > > >> On 26 March 2014 13:57, Steve Ebersole wrote: > > >> > Again from the spec (still discussing class-level Access(PROPERTY)) > : > > >> "The > > >> > behavior is undefined if mapping annotations are placed on any > instance > > >> > variables defined by the class for which Access(FIELD) is not > > >> specified". > > >> > > > >> > Which to me implies that the expectation for switching access for a > > >> > particular field within such a class is to annotate the *field* with > > >> > Access(FIELD). > > >> > > > >> > Also the footnote to this sections seems very relevant: > > >> > > > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) > or a > > >> > property as Access(FIELD)..." > > >> > > > >> > > > >> > > > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > > >> emmanuel at hibernate.org> > > >> > wrote: > > >> >> > > >> >> My reading at the time and what I did find more intuitive is what > the > > >> >> test represents. > > >> >> > > >> >> Entity level @AccessType expresses where the annotations should > > >> >> be. Otherwise the position of @Id is used to find the access type > to > > >> >> consider annotation wise. > > >> >> > > >> >> If for a few attributes I wish to use the alternative property > access, > > >> I > > >> >> can add @AccessType next to the other annotations but expressing > that > > >> >> the actual property value access is based on the alternative > access. > > >> >> That way, all annotations are in the same place. > > >> >> > > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > > >> >> > As a user I would not expect the @Access annotation to be > treated as > > >> a > > >> >> > special case by the framework in terms of when an annotation is > > >> >> > ignored, as for example that I can put this on either properties > or > > >> >> > fields, and it would not be ignored, while other annotations > could be > > >> >> > ignored depending on the position. > > >> >> > > > >> >> > Also I highly doubt that there is a practical use case to > "comment" a > > >> >> > mapping annotation by moving it to the wrong position (say I > move a > > >> >> > @GeneratedValue from a field to a property when using FIELD > access): > > >> >> > that would be extremely confusing to maintain. > > >> >> > > > >> >> > The spec's wording states "When Access(PROPERTY) is applied to an > > >> >> > [...] mapping annotations **may** be placed on .." > > >> >> > I'd stress that it doesn' t say "must" but "may", and also > doesn't > > >> >> > seem to strictly ban the opposite. > > >> >> > > > >> >> > As a user if I put a mapping annotation anywhere I expect it to > be > > >> >> > respected, so I would expect the framework to work on the union > of > > >> the > > >> >> > possible positions, and probably even to throw an exception on > > >> >> > conflicting options. The @Access property would then only be > used to > > >> >> > state which access strategy should be used (and a nice effect is > tha > > >> >> > the name becomes particularly self-explanatory too). > > >> >> > > > >> >> > Also there are many types of possible contradictions in the > mapping > > >> >> > options: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > Or you could have a stronger conflict which isn't solvable via > > >> >> > AccesType "rules" either: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > @Access(AccessType.FIELD) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > @Access(AccessType.PROPERTY) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > This last example is the reason why I think you should always > > >> >> > consistently look at both to collect mapping options, and > possibly > > >> >> > throw runtime exceptions. > > >> >> > > > >> >> > Sanne > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 26 March 2014 04:13, Steve Ebersole > wrote: > > >> >> > > >From the test > > >> >> > > > > >> >> > > > > >> > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > >> >> > > we have the following: > > >> >> > > > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test asserts that this is a valid mapping. Granted that > the > > >> spec > > >> >> > > is > > >> >> > > very unclear here, so I might be missing something. The > pertinent > > >> >> > > spec > > >> >> > > section here states: > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > *When Access(PROPERTY) is applied to an entity class, > mapped > > >> >> > > superclass, or embeddableclass, mapping annotations may be > placed > > >> on > > >> >> > > the > > >> >> > > properties of that class, and the persistenceprovider runtime > > >> accesses > > >> >> > > persistent state via the properties defined by that class. All > > >> >> > > proper-ties > > >> >> > > that are not annotated with the Transient annotation are > > >> persistent. > > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is > possible to > > >> >> > > selectively designate indi-vidual attributes within the class > for > > >> >> > > instance > > >> >> > > variable access. To specify a persistent instancevariable for > > >> access > > >> >> > > by the > > >> >> > > persistence provider runtime, that instance variable must be > > >> >> > > desig-nated > > >> >> > > Access(FIELD).* > > >> >> > > > > >> >> > > > > >> >> > > I can see a few different ways to read that: > > >> >> > > > > >> >> > > 1) @Access can be placed on the attribute to define both where > to > > >> look > > >> >> > > for > > >> >> > > mapping annotations and the runtime access strategy for a given > > >> >> > > attribute. > > >> >> > > Here, we'd do: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > 2) @Access can be placed on the attribute to define the runtime > > >> access > > >> >> > > strategy for a given attribute, but the class/hierarchy > AccessType > > >> >> > > controls > > >> >> > > where to look for mapping annotations. This would lead to: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test seems to illustrate that our legacy code made yet a > 3rd > > >> >> > > reading of > > >> >> > > this passage such that @Access is still considered a "mapping > > >> >> > > annotation" > > >> >> > > even though that seems to directly contradict "To specify a > > >> persistent > > >> >> > > instance > > >> >> > > variable for access by the persistence provider runtime, that > > >> instance > > >> >> > > variable must be desig- > > >> >> > > nated Access(FIELD)." > > >> >> > > > > >> >> > > > > >> >> > > Is there some other passage I am missing that bears on what to > do > > >> >> > > here? > > >> >> > > How do y'all feel about that passage and its implications on > this > > >> >> > > test > > >> >> > > mapping? > > >> >> > > _______________________________________________ > > >> >> > > 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 Wed Mar 26 14:42:09 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Mar 2014 18:42:09 +0000 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: On 26 March 2014 18:37, Steve Ebersole wrote: > My point is that I do not find annotating a getter method with > @Access(FIELD) to be inherently common sense. It really boils down to the > purpose/intent of @Access. If @Access *at the attribute level* is > ultimately *just* indicating how to extract/inject then I think > @Access(FIELD) on the getter does make sense. If @Access *at the attribute > level* also directs where to look for annotations (consistent with @Access > at class/hierarchy-level) then I think @AccessFile needs to be on the field > along with the other annotations, assuming we stay with non-mixed placement > for an attribute. Here a use case: as convention the team likes to put all annotations on getters, but then for some specific reason a field needs to be configured to have the ORM to use field access. Seems fair enough? Sanne > > So let's decide that first. Since the spec does not say clearly one way or > the other, I guess we have some leeway here. > > https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and > @IdSetter) plays in here as well. > > > > On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard > wrote: >> >> My take on the spec as always been that I'd rather follow the intent, >> the common sense above the letter. Likewise, I favored user experience >> over spec strict adherence. >> I did clash numerous time with the TCK in these targets but I still >> prefer that over just doing something stupid but spec to the letter. >> (this is general and not specific to that case). >> >> Anyway so my take is pretty much as it was when I first implemented >> @AccessType even if it steps over the spec at the margin. >> BTW I'm also happy if we all decide I made a usability mistake that should >> be fixed. >> >> Emmanuel >> >> On Wed 2014-03-26 11:14, Steve Ebersole wrote: >> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole >> > wrote: >> > >> > > It does violate the spec though, that's the problem: >> > > >> > >> > Well it *could* be read to violate the spec. That's inherently the >> > problem >> > with specs that use unclear wording; they can be read and argued >> > multiple >> > ways. >> > >> > >> > >> > > >> > > "... It is not permitted to specify a field as Access(PROPERTY) or a >> > > property as Access(FIELD)..." >> > > >> > > which imo is exactly what this is doing (specifying a property as >> > > FIELD): >> > > >> > > @Id >> > > @GeneratedValue >> > > @Access(AccessType.FIELD) >> > > public long getId() { >> > > return id; >> > > } >> > > >> > > >> > > >> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero >> > > wrote: >> > > >> > >> I do of course agree that people should use a single strategy and >> > >> stick to it, so I agree with your reading about what the "general >> > >> expectation" is. >> > >> >> > >> But the original test represents a quite naturally looking example >> > >> and >> > >> it's hard to justify why that should be considered illegal; I'd >> > >> probably be more inclined in making user's life easier than try to >> > >> lecture them about how a proper mapping should look like. >> > >> >> > >> Ignoring any annotation leads to waste of time and debugging >> > >> frustration, so rather than silently discarding a mis-positioned >> > >> annotation I'd prefer a fail-fast approach; that said I think just >> > >> applying them all - as long as there are no obvious conflicting >> > >> annotations - would be even more user friendly and doesn't seem to >> > >> violate any specific wording of the spec. >> > >> >> > >> Sanne >> > >> >> > >> >> > >> On 26 March 2014 13:57, Steve Ebersole wrote: >> > >> > Again from the spec (still discussing class-level Access(PROPERTY)) >> > >> > : >> > >> "The >> > >> > behavior is undefined if mapping annotations are placed on any >> > >> > instance >> > >> > variables defined by the class for which Access(FIELD) is not >> > >> specified". >> > >> > >> > >> > Which to me implies that the expectation for switching access for a >> > >> > particular field within such a class is to annotate the *field* >> > >> > with >> > >> > Access(FIELD). >> > >> > >> > >> > Also the footnote to this sections seems very relevant: >> > >> > >> > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) >> > >> > or a >> > >> > property as Access(FIELD)..." >> > >> > >> > >> > >> > >> > >> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < >> > >> emmanuel at hibernate.org> >> > >> > wrote: >> > >> >> >> > >> >> My reading at the time and what I did find more intuitive is what >> > >> >> the >> > >> >> test represents. >> > >> >> >> > >> >> Entity level @AccessType expresses where the annotations should >> > >> >> be. Otherwise the position of @Id is used to find the access type >> > >> >> to >> > >> >> consider annotation wise. >> > >> >> >> > >> >> If for a few attributes I wish to use the alternative property >> > >> >> access, >> > >> I >> > >> >> can add @AccessType next to the other annotations but expressing >> > >> >> that >> > >> >> the actual property value access is based on the alternative >> > >> >> access. >> > >> >> That way, all annotations are in the same place. >> > >> >> >> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: >> > >> >> > As a user I would not expect the @Access annotation to be >> > >> >> > treated as >> > >> a >> > >> >> > special case by the framework in terms of when an annotation is >> > >> >> > ignored, as for example that I can put this on either properties >> > >> >> > or >> > >> >> > fields, and it would not be ignored, while other annotations >> > >> >> > could be >> > >> >> > ignored depending on the position. >> > >> >> > >> > >> >> > Also I highly doubt that there is a practical use case to >> > >> >> > "comment" a >> > >> >> > mapping annotation by moving it to the wrong position (say I >> > >> >> > move a >> > >> >> > @GeneratedValue from a field to a property when using FIELD >> > >> >> > access): >> > >> >> > that would be extremely confusing to maintain. >> > >> >> > >> > >> >> > The spec's wording states "When Access(PROPERTY) is applied to >> > >> >> > an >> > >> >> > [...] mapping annotations **may** be placed on .." >> > >> >> > I'd stress that it doesn' t say "must" but "may", and also >> > >> >> > doesn't >> > >> >> > seem to strictly ban the opposite. >> > >> >> > >> > >> >> > As a user if I put a mapping annotation anywhere I expect it to >> > >> >> > be >> > >> >> > respected, so I would expect the framework to work on the union >> > >> >> > of >> > >> the >> > >> >> > possible positions, and probably even to throw an exception on >> > >> >> > conflicting options. The @Access property would then only be >> > >> >> > used to >> > >> >> > state which access strategy should be used (and a nice effect is >> > >> >> > tha >> > >> >> > the name becomes particularly self-explanatory too). >> > >> >> > >> > >> >> > Also there are many types of possible contradictions in the >> > >> >> > mapping >> > >> >> > options: >> > >> >> > >> > >> >> > public class Course { >> > >> >> > @Id @GeneratedValue(strategy=TABLE) >> > >> >> > private long id; >> > >> >> > ... >> > >> >> > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > >> >> > public long getId() { >> > >> >> > return id; >> > >> >> > } >> > >> >> > >> > >> >> > Or you could have a stronger conflict which isn't solvable via >> > >> >> > AccesType "rules" either: >> > >> >> > >> > >> >> > public class Course { >> > >> >> > @Id @GeneratedValue(strategy=TABLE) >> > >> >> > @Access(AccessType.FIELD) >> > >> >> > private long id; >> > >> >> > ... >> > >> >> > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > >> >> > @Access(AccessType.PROPERTY) >> > >> >> > public long getId() { >> > >> >> > return id; >> > >> >> > } >> > >> >> > >> > >> >> > This last example is the reason why I think you should always >> > >> >> > consistently look at both to collect mapping options, and >> > >> >> > possibly >> > >> >> > throw runtime exceptions. >> > >> >> > >> > >> >> > Sanne >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > On 26 March 2014 04:13, Steve Ebersole >> > >> >> > wrote: >> > >> >> > > >From the test >> > >> >> > > >> > >> >> > > >> > >> >> > >> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride >> > >> >> > > we have the following: >> > >> >> > > >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > The test asserts that this is a valid mapping. Granted that >> > >> >> > > the >> > >> spec >> > >> >> > > is >> > >> >> > > very unclear here, so I might be missing something. The >> > >> >> > > pertinent >> > >> >> > > spec >> > >> >> > > section here states: >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > *When Access(PROPERTY) is applied to an entity class, >> > >> >> > > mapped >> > >> >> > > superclass, or embeddableclass, mapping annotations may be >> > >> >> > > placed >> > >> on >> > >> >> > > the >> > >> >> > > properties of that class, and the persistenceprovider runtime >> > >> accesses >> > >> >> > > persistent state via the properties defined by that class. All >> > >> >> > > proper-ties >> > >> >> > > that are not annotated with the Transient annotation are >> > >> persistent. >> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is >> > >> >> > > possible to >> > >> >> > > selectively designate indi-vidual attributes within the class >> > >> >> > > for >> > >> >> > > instance >> > >> >> > > variable access. To specify a persistent instancevariable for >> > >> access >> > >> >> > > by the >> > >> >> > > persistence provider runtime, that instance variable must be >> > >> >> > > desig-nated >> > >> >> > > Access(FIELD).* >> > >> >> > > >> > >> >> > > >> > >> >> > > I can see a few different ways to read that: >> > >> >> > > >> > >> >> > > 1) @Access can be placed on the attribute to define both where >> > >> >> > > to >> > >> look >> > >> >> > > for >> > >> >> > > mapping annotations and the runtime access strategy for a >> > >> >> > > given >> > >> >> > > attribute. >> > >> >> > > Here, we'd do: >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > 2) @Access can be placed on the attribute to define the >> > >> >> > > runtime >> > >> access >> > >> >> > > strategy for a given attribute, but the class/hierarchy >> > >> >> > > AccessType >> > >> >> > > controls >> > >> >> > > where to look for mapping annotations. This would lead to: >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > The test seems to illustrate that our legacy code made yet a >> > >> >> > > 3rd >> > >> >> > > reading of >> > >> >> > > this passage such that @Access is still considered a "mapping >> > >> >> > > annotation" >> > >> >> > > even though that seems to directly contradict "To specify a >> > >> persistent >> > >> >> > > instance >> > >> >> > > variable for access by the persistence provider runtime, that >> > >> instance >> > >> >> > > variable must be desig- >> > >> >> > > nated Access(FIELD)." >> > >> >> > > >> > >> >> > > >> > >> >> > > Is there some other passage I am missing that bears on what to >> > >> >> > > do >> > >> >> > > here? >> > >> >> > > How do y'all feel about that passage and its implications on >> > >> >> > > this >> > >> >> > > test >> > >> >> > > mapping? >> > >> >> > > _______________________________________________ >> > >> >> > > 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 steve at hibernate.org Wed Mar 26 14:46:38 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 13:46:38 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: All I can do is quote myself again ;) If @Access *at the attribute level* is ultimately *just* indicating how to extract/inject then I think @Access(FIELD) on the getter does make sense. On Wed, Mar 26, 2014 at 1:42 PM, Sanne Grinovero wrote: > On 26 March 2014 18:37, Steve Ebersole wrote: > > My point is that I do not find annotating a getter method with > > @Access(FIELD) to be inherently common sense. It really boils down to > the > > purpose/intent of @Access. If @Access *at the attribute level* is > > ultimately *just* indicating how to extract/inject then I think > > @Access(FIELD) on the getter does make sense. If @Access *at the > attribute > > level* also directs where to look for annotations (consistent with > @Access > > at class/hierarchy-level) then I think @AccessFile needs to be on the > field > > along with the other annotations, assuming we stay with non-mixed > placement > > for an attribute. > > Here a use case: as convention the team likes to put all annotations > on getters, but then for some specific reason a field needs to be > configured to have the ORM to use field access. > Seems fair enough? > > Sanne > > > > > So let's decide that first. Since the spec does not say clearly one way > or > > the other, I guess we have some leeway here. > > > > https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and > > @IdSetter) plays in here as well. > > > > > > > > On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard < > emmanuel at hibernate.org> > > wrote: > >> > >> My take on the spec as always been that I'd rather follow the intent, > >> the common sense above the letter. Likewise, I favored user experience > >> over spec strict adherence. > >> I did clash numerous time with the TCK in these targets but I still > >> prefer that over just doing something stupid but spec to the letter. > >> (this is general and not specific to that case). > >> > >> Anyway so my take is pretty much as it was when I first implemented > >> @AccessType even if it steps over the spec at the margin. > >> BTW I'm also happy if we all decide I made a usability mistake that > should > >> be fixed. > >> > >> Emmanuel > >> > >> On Wed 2014-03-26 11:14, Steve Ebersole wrote: > >> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole > >> > wrote: > >> > > >> > > It does violate the spec though, that's the problem: > >> > > > >> > > >> > Well it *could* be read to violate the spec. That's inherently the > >> > problem > >> > with specs that use unclear wording; they can be read and argued > >> > multiple > >> > ways. > >> > > >> > > >> > > >> > > > >> > > "... It is not permitted to specify a field as Access(PROPERTY) or a > >> > > property as Access(FIELD)..." > >> > > > >> > > which imo is exactly what this is doing (specifying a property as > >> > > FIELD): > >> > > > >> > > @Id > >> > > @GeneratedValue > >> > > @Access(AccessType.FIELD) > >> > > public long getId() { > >> > > return id; > >> > > } > >> > > > >> > > > >> > > > >> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero > >> > > wrote: > >> > > > >> > >> I do of course agree that people should use a single strategy and > >> > >> stick to it, so I agree with your reading about what the "general > >> > >> expectation" is. > >> > >> > >> > >> But the original test represents a quite naturally looking example > >> > >> and > >> > >> it's hard to justify why that should be considered illegal; I'd > >> > >> probably be more inclined in making user's life easier than try to > >> > >> lecture them about how a proper mapping should look like. > >> > >> > >> > >> Ignoring any annotation leads to waste of time and debugging > >> > >> frustration, so rather than silently discarding a mis-positioned > >> > >> annotation I'd prefer a fail-fast approach; that said I think just > >> > >> applying them all - as long as there are no obvious conflicting > >> > >> annotations - would be even more user friendly and doesn't seem to > >> > >> violate any specific wording of the spec. > >> > >> > >> > >> Sanne > >> > >> > >> > >> > >> > >> On 26 March 2014 13:57, Steve Ebersole > wrote: > >> > >> > Again from the spec (still discussing class-level > Access(PROPERTY)) > >> > >> > : > >> > >> "The > >> > >> > behavior is undefined if mapping annotations are placed on any > >> > >> > instance > >> > >> > variables defined by the class for which Access(FIELD) is not > >> > >> specified". > >> > >> > > >> > >> > Which to me implies that the expectation for switching access > for a > >> > >> > particular field within such a class is to annotate the *field* > >> > >> > with > >> > >> > Access(FIELD). > >> > >> > > >> > >> > Also the footnote to this sections seems very relevant: > >> > >> > > >> > >> > "[8] ... It is not permitted to specify a field as > Access(PROPERTY) > >> > >> > or a > >> > >> > property as Access(FIELD)..." > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > >> > >> emmanuel at hibernate.org> > >> > >> > wrote: > >> > >> >> > >> > >> >> My reading at the time and what I did find more intuitive is > what > >> > >> >> the > >> > >> >> test represents. > >> > >> >> > >> > >> >> Entity level @AccessType expresses where the annotations should > >> > >> >> be. Otherwise the position of @Id is used to find the access > type > >> > >> >> to > >> > >> >> consider annotation wise. > >> > >> >> > >> > >> >> If for a few attributes I wish to use the alternative property > >> > >> >> access, > >> > >> I > >> > >> >> can add @AccessType next to the other annotations but expressing > >> > >> >> that > >> > >> >> the actual property value access is based on the alternative > >> > >> >> access. > >> > >> >> That way, all annotations are in the same place. > >> > >> >> > >> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > >> > >> >> > As a user I would not expect the @Access annotation to be > >> > >> >> > treated as > >> > >> a > >> > >> >> > special case by the framework in terms of when an annotation > is > >> > >> >> > ignored, as for example that I can put this on either > properties > >> > >> >> > or > >> > >> >> > fields, and it would not be ignored, while other annotations > >> > >> >> > could be > >> > >> >> > ignored depending on the position. > >> > >> >> > > >> > >> >> > Also I highly doubt that there is a practical use case to > >> > >> >> > "comment" a > >> > >> >> > mapping annotation by moving it to the wrong position (say I > >> > >> >> > move a > >> > >> >> > @GeneratedValue from a field to a property when using FIELD > >> > >> >> > access): > >> > >> >> > that would be extremely confusing to maintain. > >> > >> >> > > >> > >> >> > The spec's wording states "When Access(PROPERTY) is applied to > >> > >> >> > an > >> > >> >> > [...] mapping annotations **may** be placed on .." > >> > >> >> > I'd stress that it doesn' t say "must" but "may", and also > >> > >> >> > doesn't > >> > >> >> > seem to strictly ban the opposite. > >> > >> >> > > >> > >> >> > As a user if I put a mapping annotation anywhere I expect it > to > >> > >> >> > be > >> > >> >> > respected, so I would expect the framework to work on the > union > >> > >> >> > of > >> > >> the > >> > >> >> > possible positions, and probably even to throw an exception on > >> > >> >> > conflicting options. The @Access property would then only be > >> > >> >> > used to > >> > >> >> > state which access strategy should be used (and a nice effect > is > >> > >> >> > tha > >> > >> >> > the name becomes particularly self-explanatory too). > >> > >> >> > > >> > >> >> > Also there are many types of possible contradictions in the > >> > >> >> > mapping > >> > >> >> > options: > >> > >> >> > > >> > >> >> > public class Course { > >> > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> > >> >> > private long id; > >> > >> >> > ... > >> > >> >> > > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > >> >> > public long getId() { > >> > >> >> > return id; > >> > >> >> > } > >> > >> >> > > >> > >> >> > Or you could have a stronger conflict which isn't solvable via > >> > >> >> > AccesType "rules" either: > >> > >> >> > > >> > >> >> > public class Course { > >> > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> > >> >> > @Access(AccessType.FIELD) > >> > >> >> > private long id; > >> > >> >> > ... > >> > >> >> > > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > >> >> > @Access(AccessType.PROPERTY) > >> > >> >> > public long getId() { > >> > >> >> > return id; > >> > >> >> > } > >> > >> >> > > >> > >> >> > This last example is the reason why I think you should always > >> > >> >> > consistently look at both to collect mapping options, and > >> > >> >> > possibly > >> > >> >> > throw runtime exceptions. > >> > >> >> > > >> > >> >> > Sanne > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On 26 March 2014 04:13, Steve Ebersole > >> > >> >> > wrote: > >> > >> >> > > >From the test > >> > >> >> > > > >> > >> >> > > > >> > >> > >> > >> > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > >> > >> >> > > we have the following: > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > The test asserts that this is a valid mapping. Granted that > >> > >> >> > > the > >> > >> spec > >> > >> >> > > is > >> > >> >> > > very unclear here, so I might be missing something. The > >> > >> >> > > pertinent > >> > >> >> > > spec > >> > >> >> > > section here states: > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > *When Access(PROPERTY) is applied to an entity class, > >> > >> >> > > mapped > >> > >> >> > > superclass, or embeddableclass, mapping annotations may be > >> > >> >> > > placed > >> > >> on > >> > >> >> > > the > >> > >> >> > > properties of that class, and the persistenceprovider > runtime > >> > >> accesses > >> > >> >> > > persistent state via the properties defined by that class. > All > >> > >> >> > > proper-ties > >> > >> >> > > that are not annotated with the Transient annotation are > >> > >> persistent. > >> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is > >> > >> >> > > possible to > >> > >> >> > > selectively designate indi-vidual attributes within the > class > >> > >> >> > > for > >> > >> >> > > instance > >> > >> >> > > variable access. To specify a persistent instancevariable > for > >> > >> access > >> > >> >> > > by the > >> > >> >> > > persistence provider runtime, that instance variable must be > >> > >> >> > > desig-nated > >> > >> >> > > Access(FIELD).* > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > I can see a few different ways to read that: > >> > >> >> > > > >> > >> >> > > 1) @Access can be placed on the attribute to define both > where > >> > >> >> > > to > >> > >> look > >> > >> >> > > for > >> > >> >> > > mapping annotations and the runtime access strategy for a > >> > >> >> > > given > >> > >> >> > > attribute. > >> > >> >> > > Here, we'd do: > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > 2) @Access can be placed on the attribute to define the > >> > >> >> > > runtime > >> > >> access > >> > >> >> > > strategy for a given attribute, but the class/hierarchy > >> > >> >> > > AccessType > >> > >> >> > > controls > >> > >> >> > > where to look for mapping annotations. This would lead to: > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > The test seems to illustrate that our legacy code made yet a > >> > >> >> > > 3rd > >> > >> >> > > reading of > >> > >> >> > > this passage such that @Access is still considered a > "mapping > >> > >> >> > > annotation" > >> > >> >> > > even though that seems to directly contradict "To specify a > >> > >> persistent > >> > >> >> > > instance > >> > >> >> > > variable for access by the persistence provider runtime, > that > >> > >> instance > >> > >> >> > > variable must be desig- > >> > >> >> > > nated Access(FIELD)." > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > Is there some other passage I am missing that bears on what > to > >> > >> >> > > do > >> > >> >> > > here? > >> > >> >> > > How do y'all feel about that passage and its implications > on > >> > >> >> > > this > >> > >> >> > > test > >> > >> >> > > mapping? > >> > >> >> > > _______________________________________________ > >> > >> >> > > 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 Mar 26 15:01:15 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 20:01:15 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: On 26 Jan 2014, at 05:13, Steve Ebersole wrote: >> From the test > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > we have the following: > > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > private long id; > ... > > @Id > @GeneratedValue > @Access(AccessType.FIELD) > public long getId() { > return id; > } > ... > } > > The test asserts that this is a valid mapping. Granted that the spec is > very unclear here, so I might be missing something. The pertinent spec > section here states: For what its worth, I think the mapping is not valid (according to my interpretation of the spec). @Access(AccessType.FIELD) would need to be specified on the field to take effect. Whether this mapping is valid in a sense that is ignores @Access(AccessType.FIELD) is a different question. However, referring to your test, afaics the test and class in question (Course3) uses @org.hibernate.annotations.AccessType("field?) which is a different thing altogether. Here we are dealing with the now deprecated org.hibernate.annotations.AccessType annotation. AFAIK, this annotation used to be placed together with other mapping annotations. So what do we want to discuss here really? ?Hardy From steve at hibernate.org Wed Mar 26 15:05:09 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 14:05:09 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: Hardy, not sure where you are looking... But in master Course3 DOES NOT use @org.hibernate.annotations.AccessType... On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 05:13, Steve Ebersole wrote: > > >> From the test > > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > we have the following: > > > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > private long id; > > ... > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > ... > > } > > > > The test asserts that this is a valid mapping. Granted that the spec is > > very unclear here, so I might be missing something. The pertinent spec > > section here states: > > For what its worth, I think the mapping is not valid (according to my > interpretation of the spec). > @Access(AccessType.FIELD) would need to be specified on the field to take > effect. Whether this mapping > is valid in a sense that is ignores @Access(AccessType.FIELD) is a > different question. > > However, referring to your test, afaics the test and class in question > (Course3) uses > @org.hibernate.annotations.AccessType("field") which is a different thing > altogether. Here we are dealing > with the now deprecated org.hibernate.annotations.AccessType annotation. > AFAIK, this annotation used > to be placed together with other mapping annotations. > > So what do we want to discuss here really? > > --Hardy > > > > > > > From steve at hibernate.org Wed Mar 26 15:08:55 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 14:08:55 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: To be clear Sanne, I am not arguing with your point or point-of-view. I am just saying that we should have a concise, consistent answer as to what AccessType means. We do not have that today. And just to point out, allowing @Access(FIELD) on a getter makes it operate inconsistently from @Acess(FIELD) on a class. Again, that does not make it wrong, but we need to understand that inconsistency and be able to justify it. On Wed, Mar 26, 2014 at 1:42 PM, Sanne Grinovero wrote: > On 26 March 2014 18:37, Steve Ebersole wrote: > > My point is that I do not find annotating a getter method with > > @Access(FIELD) to be inherently common sense. It really boils down to > the > > purpose/intent of @Access. If @Access *at the attribute level* is > > ultimately *just* indicating how to extract/inject then I think > > @Access(FIELD) on the getter does make sense. If @Access *at the > attribute > > level* also directs where to look for annotations (consistent with > @Access > > at class/hierarchy-level) then I think @AccessFile needs to be on the > field > > along with the other annotations, assuming we stay with non-mixed > placement > > for an attribute. > > Here a use case: as convention the team likes to put all annotations > on getters, but then for some specific reason a field needs to be > configured to have the ORM to use field access. > Seems fair enough? > > Sanne > > > > > So let's decide that first. Since the spec does not say clearly one way > or > > the other, I guess we have some leeway here. > > > > https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and > > @IdSetter) plays in here as well. > > > > > > > > On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard < > emmanuel at hibernate.org> > > wrote: > >> > >> My take on the spec as always been that I'd rather follow the intent, > >> the common sense above the letter. Likewise, I favored user experience > >> over spec strict adherence. > >> I did clash numerous time with the TCK in these targets but I still > >> prefer that over just doing something stupid but spec to the letter. > >> (this is general and not specific to that case). > >> > >> Anyway so my take is pretty much as it was when I first implemented > >> @AccessType even if it steps over the spec at the margin. > >> BTW I'm also happy if we all decide I made a usability mistake that > should > >> be fixed. > >> > >> Emmanuel > >> > >> On Wed 2014-03-26 11:14, Steve Ebersole wrote: > >> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole > >> > wrote: > >> > > >> > > It does violate the spec though, that's the problem: > >> > > > >> > > >> > Well it *could* be read to violate the spec. That's inherently the > >> > problem > >> > with specs that use unclear wording; they can be read and argued > >> > multiple > >> > ways. > >> > > >> > > >> > > >> > > > >> > > "... It is not permitted to specify a field as Access(PROPERTY) or a > >> > > property as Access(FIELD)..." > >> > > > >> > > which imo is exactly what this is doing (specifying a property as > >> > > FIELD): > >> > > > >> > > @Id > >> > > @GeneratedValue > >> > > @Access(AccessType.FIELD) > >> > > public long getId() { > >> > > return id; > >> > > } > >> > > > >> > > > >> > > > >> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero > >> > > wrote: > >> > > > >> > >> I do of course agree that people should use a single strategy and > >> > >> stick to it, so I agree with your reading about what the "general > >> > >> expectation" is. > >> > >> > >> > >> But the original test represents a quite naturally looking example > >> > >> and > >> > >> it's hard to justify why that should be considered illegal; I'd > >> > >> probably be more inclined in making user's life easier than try to > >> > >> lecture them about how a proper mapping should look like. > >> > >> > >> > >> Ignoring any annotation leads to waste of time and debugging > >> > >> frustration, so rather than silently discarding a mis-positioned > >> > >> annotation I'd prefer a fail-fast approach; that said I think just > >> > >> applying them all - as long as there are no obvious conflicting > >> > >> annotations - would be even more user friendly and doesn't seem to > >> > >> violate any specific wording of the spec. > >> > >> > >> > >> Sanne > >> > >> > >> > >> > >> > >> On 26 March 2014 13:57, Steve Ebersole > wrote: > >> > >> > Again from the spec (still discussing class-level > Access(PROPERTY)) > >> > >> > : > >> > >> "The > >> > >> > behavior is undefined if mapping annotations are placed on any > >> > >> > instance > >> > >> > variables defined by the class for which Access(FIELD) is not > >> > >> specified". > >> > >> > > >> > >> > Which to me implies that the expectation for switching access > for a > >> > >> > particular field within such a class is to annotate the *field* > >> > >> > with > >> > >> > Access(FIELD). > >> > >> > > >> > >> > Also the footnote to this sections seems very relevant: > >> > >> > > >> > >> > "[8] ... It is not permitted to specify a field as > Access(PROPERTY) > >> > >> > or a > >> > >> > property as Access(FIELD)..." > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > >> > >> emmanuel at hibernate.org> > >> > >> > wrote: > >> > >> >> > >> > >> >> My reading at the time and what I did find more intuitive is > what > >> > >> >> the > >> > >> >> test represents. > >> > >> >> > >> > >> >> Entity level @AccessType expresses where the annotations should > >> > >> >> be. Otherwise the position of @Id is used to find the access > type > >> > >> >> to > >> > >> >> consider annotation wise. > >> > >> >> > >> > >> >> If for a few attributes I wish to use the alternative property > >> > >> >> access, > >> > >> I > >> > >> >> can add @AccessType next to the other annotations but expressing > >> > >> >> that > >> > >> >> the actual property value access is based on the alternative > >> > >> >> access. > >> > >> >> That way, all annotations are in the same place. > >> > >> >> > >> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > >> > >> >> > As a user I would not expect the @Access annotation to be > >> > >> >> > treated as > >> > >> a > >> > >> >> > special case by the framework in terms of when an annotation > is > >> > >> >> > ignored, as for example that I can put this on either > properties > >> > >> >> > or > >> > >> >> > fields, and it would not be ignored, while other annotations > >> > >> >> > could be > >> > >> >> > ignored depending on the position. > >> > >> >> > > >> > >> >> > Also I highly doubt that there is a practical use case to > >> > >> >> > "comment" a > >> > >> >> > mapping annotation by moving it to the wrong position (say I > >> > >> >> > move a > >> > >> >> > @GeneratedValue from a field to a property when using FIELD > >> > >> >> > access): > >> > >> >> > that would be extremely confusing to maintain. > >> > >> >> > > >> > >> >> > The spec's wording states "When Access(PROPERTY) is applied to > >> > >> >> > an > >> > >> >> > [...] mapping annotations **may** be placed on .." > >> > >> >> > I'd stress that it doesn' t say "must" but "may", and also > >> > >> >> > doesn't > >> > >> >> > seem to strictly ban the opposite. > >> > >> >> > > >> > >> >> > As a user if I put a mapping annotation anywhere I expect it > to > >> > >> >> > be > >> > >> >> > respected, so I would expect the framework to work on the > union > >> > >> >> > of > >> > >> the > >> > >> >> > possible positions, and probably even to throw an exception on > >> > >> >> > conflicting options. The @Access property would then only be > >> > >> >> > used to > >> > >> >> > state which access strategy should be used (and a nice effect > is > >> > >> >> > tha > >> > >> >> > the name becomes particularly self-explanatory too). > >> > >> >> > > >> > >> >> > Also there are many types of possible contradictions in the > >> > >> >> > mapping > >> > >> >> > options: > >> > >> >> > > >> > >> >> > public class Course { > >> > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> > >> >> > private long id; > >> > >> >> > ... > >> > >> >> > > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > >> >> > public long getId() { > >> > >> >> > return id; > >> > >> >> > } > >> > >> >> > > >> > >> >> > Or you could have a stronger conflict which isn't solvable via > >> > >> >> > AccesType "rules" either: > >> > >> >> > > >> > >> >> > public class Course { > >> > >> >> > @Id @GeneratedValue(strategy=TABLE) > >> > >> >> > @Access(AccessType.FIELD) > >> > >> >> > private long id; > >> > >> >> > ... > >> > >> >> > > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > >> > >> >> > @Access(AccessType.PROPERTY) > >> > >> >> > public long getId() { > >> > >> >> > return id; > >> > >> >> > } > >> > >> >> > > >> > >> >> > This last example is the reason why I think you should always > >> > >> >> > consistently look at both to collect mapping options, and > >> > >> >> > possibly > >> > >> >> > throw runtime exceptions. > >> > >> >> > > >> > >> >> > Sanne > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On 26 March 2014 04:13, Steve Ebersole > >> > >> >> > wrote: > >> > >> >> > > >From the test > >> > >> >> > > > >> > >> >> > > > >> > >> > >> > >> > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > >> > >> >> > > we have the following: > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > The test asserts that this is a valid mapping. Granted that > >> > >> >> > > the > >> > >> spec > >> > >> >> > > is > >> > >> >> > > very unclear here, so I might be missing something. The > >> > >> >> > > pertinent > >> > >> >> > > spec > >> > >> >> > > section here states: > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > *When Access(PROPERTY) is applied to an entity class, > >> > >> >> > > mapped > >> > >> >> > > superclass, or embeddableclass, mapping annotations may be > >> > >> >> > > placed > >> > >> on > >> > >> >> > > the > >> > >> >> > > properties of that class, and the persistenceprovider > runtime > >> > >> accesses > >> > >> >> > > persistent state via the properties defined by that class. > All > >> > >> >> > > proper-ties > >> > >> >> > > that are not annotated with the Transient annotation are > >> > >> persistent. > >> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is > >> > >> >> > > possible to > >> > >> >> > > selectively designate indi-vidual attributes within the > class > >> > >> >> > > for > >> > >> >> > > instance > >> > >> >> > > variable access. To specify a persistent instancevariable > for > >> > >> access > >> > >> >> > > by the > >> > >> >> > > persistence provider runtime, that instance variable must be > >> > >> >> > > desig-nated > >> > >> >> > > Access(FIELD).* > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > I can see a few different ways to read that: > >> > >> >> > > > >> > >> >> > > 1) @Access can be placed on the attribute to define both > where > >> > >> >> > > to > >> > >> look > >> > >> >> > > for > >> > >> >> > > mapping annotations and the runtime access strategy for a > >> > >> >> > > given > >> > >> >> > > attribute. > >> > >> >> > > Here, we'd do: > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > 2) @Access can be placed on the attribute to define the > >> > >> >> > > runtime > >> > >> access > >> > >> >> > > strategy for a given attribute, but the class/hierarchy > >> > >> >> > > AccessType > >> > >> >> > > controls > >> > >> >> > > where to look for mapping annotations. This would lead to: > >> > >> >> > > > >> > >> >> > > @Entity > >> > >> >> > > @Access(AccessType.PROPERTY) > >> > >> >> > > public class Course3 { > >> > >> >> > > @Access(AccessType.FIELD) > >> > >> >> > > private long id; > >> > >> >> > > ... > >> > >> >> > > > >> > >> >> > > @Id > >> > >> >> > > @GeneratedValue > >> > >> >> > > public long getId() { > >> > >> >> > > return id; > >> > >> >> > > } > >> > >> >> > > ... > >> > >> >> > > } > >> > >> >> > > > >> > >> >> > > The test seems to illustrate that our legacy code made yet a > >> > >> >> > > 3rd > >> > >> >> > > reading of > >> > >> >> > > this passage such that @Access is still considered a > "mapping > >> > >> >> > > annotation" > >> > >> >> > > even though that seems to directly contradict "To specify a > >> > >> persistent > >> > >> >> > > instance > >> > >> >> > > variable for access by the persistence provider runtime, > that > >> > >> instance > >> > >> >> > > variable must be desig- > >> > >> >> > > nated Access(FIELD)." > >> > >> >> > > > >> > >> >> > > > >> > >> >> > > Is there some other passage I am missing that bears on what > to > >> > >> >> > > do > >> > >> >> > > here? > >> > >> >> > > How do y'all feel about that passage and its implications > on > >> > >> >> > > this > >> > >> >> > > test > >> > >> >> > > mapping? > >> > >> >> > > _______________________________________________ > >> > >> >> > > 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 Mar 26 15:14:39 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 20:14:39 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: Message-ID: <6FB133B2-B049-4B60-9F38-61E219B66B98@hibernate.org> Hi, you are right, the current code used @Access(AccessType.FIELD) - https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/src/test/java/org/hibernate/test/annotations/access/jpa/Course3.java However, this is wrong. I actually looked first in my local checkout which is a bit outdated, but there @org.hibernate.annotations.AccessType is still used. Judging by the test name this was clearly the intent of the test as well. It seems the test got changed a month ago in order to fix test failures - https://github.com/hibernate/hibernate-orm/commit/ff12d5c#diff-40 In this case the change was wrong. I guess the idea was to get rid of the deprecated annotation use, but the whole test should have been deleted. ?Hardy On 26 Jan 2014, at 20:05, Steve Ebersole wrote: > Hardy, not sure where you are looking... But in master Course3 DOES NOT use @org.hibernate.annotations.AccessType... > > > On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 05:13, Steve Ebersole wrote: > > >> From the test > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > we have the following: > > > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > private long id; > > ... > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > ... > > } > > > > The test asserts that this is a valid mapping. Granted that the spec is > > very unclear here, so I might be missing something. The pertinent spec > > section here states: > > For what its worth, I think the mapping is not valid (according to my interpretation of the spec). > @Access(AccessType.FIELD) would need to be specified on the field to take effect. Whether this mapping > is valid in a sense that is ignores @Access(AccessType.FIELD) is a different question. > > However, referring to your test, afaics the test and class in question (Course3) uses > @org.hibernate.annotations.AccessType("field?) which is a different thing altogether. Here we are dealing > with the now deprecated org.hibernate.annotations.AccessType annotation. AFAIK, this annotation used > to be placed together with other mapping annotations. > > So what do we want to discuss here really? > > ?Hardy > > > > > > > From steve at hibernate.org Wed Mar 26 15:14:50 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 14:14:50 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <20140326162159.GK42990@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: So the spec does specifically say "It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)". I understanding making usability choices when the spec is unclear. Do you think there is non-clarity in that quote though? Even if you say making usability choices when the spec is very clear, but "wrong"... again I can live with that. But we need to be clear about that. On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard wrote: > My take on the spec as always been that I'd rather follow the intent, > the common sense above the letter. Likewise, I favored user experience > over spec strict adherence. > I did clash numerous time with the TCK in these targets but I still > prefer that over just doing something stupid but spec to the letter. > (this is general and not specific to that case). > > Anyway so my take is pretty much as it was when I first implemented > @AccessType even if it steps over the spec at the margin. > BTW I'm also happy if we all decide I made a usability mistake that should > be fixed. > > Emmanuel > > On Wed 2014-03-26 11:14, Steve Ebersole wrote: > > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole >wrote: > > > > > It does violate the spec though, that's the problem: > > > > > > > Well it *could* be read to violate the spec. That's inherently the > problem > > with specs that use unclear wording; they can be read and argued multiple > > ways. > > > > > > > > > > > > "... It is not permitted to specify a field as Access(PROPERTY) or a > > > property as Access(FIELD)..." > > > > > > which imo is exactly what this is doing (specifying a property as > FIELD): > > > > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > public long getId() { > > > return id; > > > } > > > > > > > > > > > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero >wrote: > > > > > >> I do of course agree that people should use a single strategy and > > >> stick to it, so I agree with your reading about what the "general > > >> expectation" is. > > >> > > >> But the original test represents a quite naturally looking example and > > >> it's hard to justify why that should be considered illegal; I'd > > >> probably be more inclined in making user's life easier than try to > > >> lecture them about how a proper mapping should look like. > > >> > > >> Ignoring any annotation leads to waste of time and debugging > > >> frustration, so rather than silently discarding a mis-positioned > > >> annotation I'd prefer a fail-fast approach; that said I think just > > >> applying them all - as long as there are no obvious conflicting > > >> annotations - would be even more user friendly and doesn't seem to > > >> violate any specific wording of the spec. > > >> > > >> Sanne > > >> > > >> > > >> On 26 March 2014 13:57, Steve Ebersole wrote: > > >> > Again from the spec (still discussing class-level Access(PROPERTY)) > : > > >> "The > > >> > behavior is undefined if mapping annotations are placed on any > instance > > >> > variables defined by the class for which Access(FIELD) is not > > >> specified". > > >> > > > >> > Which to me implies that the expectation for switching access for a > > >> > particular field within such a class is to annotate the *field* with > > >> > Access(FIELD). > > >> > > > >> > Also the footnote to this sections seems very relevant: > > >> > > > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) > or a > > >> > property as Access(FIELD)..." > > >> > > > >> > > > >> > > > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > > >> emmanuel at hibernate.org> > > >> > wrote: > > >> >> > > >> >> My reading at the time and what I did find more intuitive is what > the > > >> >> test represents. > > >> >> > > >> >> Entity level @AccessType expresses where the annotations should > > >> >> be. Otherwise the position of @Id is used to find the access type > to > > >> >> consider annotation wise. > > >> >> > > >> >> If for a few attributes I wish to use the alternative property > access, > > >> I > > >> >> can add @AccessType next to the other annotations but expressing > that > > >> >> the actual property value access is based on the alternative > access. > > >> >> That way, all annotations are in the same place. > > >> >> > > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > > >> >> > As a user I would not expect the @Access annotation to be > treated as > > >> a > > >> >> > special case by the framework in terms of when an annotation is > > >> >> > ignored, as for example that I can put this on either properties > or > > >> >> > fields, and it would not be ignored, while other annotations > could be > > >> >> > ignored depending on the position. > > >> >> > > > >> >> > Also I highly doubt that there is a practical use case to > "comment" a > > >> >> > mapping annotation by moving it to the wrong position (say I > move a > > >> >> > @GeneratedValue from a field to a property when using FIELD > access): > > >> >> > that would be extremely confusing to maintain. > > >> >> > > > >> >> > The spec's wording states "When Access(PROPERTY) is applied to an > > >> >> > [...] mapping annotations **may** be placed on .." > > >> >> > I'd stress that it doesn' t say "must" but "may", and also > doesn't > > >> >> > seem to strictly ban the opposite. > > >> >> > > > >> >> > As a user if I put a mapping annotation anywhere I expect it to > be > > >> >> > respected, so I would expect the framework to work on the union > of > > >> the > > >> >> > possible positions, and probably even to throw an exception on > > >> >> > conflicting options. The @Access property would then only be > used to > > >> >> > state which access strategy should be used (and a nice effect is > tha > > >> >> > the name becomes particularly self-explanatory too). > > >> >> > > > >> >> > Also there are many types of possible contradictions in the > mapping > > >> >> > options: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > Or you could have a stronger conflict which isn't solvable via > > >> >> > AccesType "rules" either: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > @Access(AccessType.FIELD) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > @Access(AccessType.PROPERTY) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > This last example is the reason why I think you should always > > >> >> > consistently look at both to collect mapping options, and > possibly > > >> >> > throw runtime exceptions. > > >> >> > > > >> >> > Sanne > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 26 March 2014 04:13, Steve Ebersole > wrote: > > >> >> > > >From the test > > >> >> > > > > >> >> > > > > >> > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > >> >> > > we have the following: > > >> >> > > > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test asserts that this is a valid mapping. Granted that > the > > >> spec > > >> >> > > is > > >> >> > > very unclear here, so I might be missing something. The > pertinent > > >> >> > > spec > > >> >> > > section here states: > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > *When Access(PROPERTY) is applied to an entity class, > mapped > > >> >> > > superclass, or embeddableclass, mapping annotations may be > placed > > >> on > > >> >> > > the > > >> >> > > properties of that class, and the persistenceprovider runtime > > >> accesses > > >> >> > > persistent state via the properties defined by that class. All > > >> >> > > proper-ties > > >> >> > > that are not annotated with the Transient annotation are > > >> persistent. > > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is > possible to > > >> >> > > selectively designate indi-vidual attributes within the class > for > > >> >> > > instance > > >> >> > > variable access. To specify a persistent instancevariable for > > >> access > > >> >> > > by the > > >> >> > > persistence provider runtime, that instance variable must be > > >> >> > > desig-nated > > >> >> > > Access(FIELD).* > > >> >> > > > > >> >> > > > > >> >> > > I can see a few different ways to read that: > > >> >> > > > > >> >> > > 1) @Access can be placed on the attribute to define both where > to > > >> look > > >> >> > > for > > >> >> > > mapping annotations and the runtime access strategy for a given > > >> >> > > attribute. > > >> >> > > Here, we'd do: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > 2) @Access can be placed on the attribute to define the runtime > > >> access > > >> >> > > strategy for a given attribute, but the class/hierarchy > AccessType > > >> >> > > controls > > >> >> > > where to look for mapping annotations. This would lead to: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test seems to illustrate that our legacy code made yet a > 3rd > > >> >> > > reading of > > >> >> > > this passage such that @Access is still considered a "mapping > > >> >> > > annotation" > > >> >> > > even though that seems to directly contradict "To specify a > > >> persistent > > >> >> > > instance > > >> >> > > variable for access by the persistence provider runtime, that > > >> instance > > >> >> > > variable must be desig- > > >> >> > > nated Access(FIELD)." > > >> >> > > > > >> >> > > > > >> >> > > Is there some other passage I am missing that bears on what to > do > > >> >> > > here? > > >> >> > > How do y'all feel about that passage and its implications on > this > > >> >> > > test > > >> >> > > mapping? > > >> >> > > _______________________________________________ > > >> >> > > 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 steve at hibernate.org Wed Mar 26 15:16:36 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 14:16:36 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <6FB133B2-B049-4B60-9F38-61E219B66B98@hibernate.org> References: <6FB133B2-B049-4B60-9F38-61E219B66B98@hibernate.org> Message-ID: Ok, but... its still a good spring board to discuss this topic which is strangely unclear and murky in terms of what we do and do not support. On Wed, Mar 26, 2014 at 2:14 PM, Hardy Ferentschik wrote: > Hi, > > you are right, the current code used @Access(AccessType.FIELD) - > https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/src/test/java/org/hibernate/test/annotations/access/jpa/Course3.java > However, this is wrong. I actually looked first in my local checkout which > is a bit outdated, but there @org.hibernate.annotations.AccessType is still > used. > Judging by the test name this was clearly the intent of the test as well. > > It seems the test got changed a month ago in order to fix test failures - > https://github.com/hibernate/hibernate-orm/commit/ff12d5c#diff-40 > In this case the change was wrong. I guess the idea was to get rid of the > deprecated annotation use, but the whole test should have been deleted. > > --Hardy > > > > On 26 Jan 2014, at 20:05, Steve Ebersole wrote: > > > Hardy, not sure where you are looking... But in master Course3 DOES NOT > use @org.hibernate.annotations.AccessType... > > > > > > On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik > wrote: > > > > On 26 Jan 2014, at 05:13, Steve Ebersole wrote: > > > > >> From the test > > > > org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > > we have the following: > > > > > > > > > @Entity > > > @Access(AccessType.PROPERTY) > > > public class Course3 { > > > private long id; > > > ... > > > > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > public long getId() { > > > return id; > > > } > > > ... > > > } > > > > > > The test asserts that this is a valid mapping. Granted that the spec > is > > > very unclear here, so I might be missing something. The pertinent spec > > > section here states: > > > > For what its worth, I think the mapping is not valid (according to my > interpretation of the spec). > > @Access(AccessType.FIELD) would need to be specified on the field to > take effect. Whether this mapping > > is valid in a sense that is ignores @Access(AccessType.FIELD) is a > different question. > > > > However, referring to your test, afaics the test and class in question > (Course3) uses > > @org.hibernate.annotations.AccessType("field") which is a different > thing altogether. Here we are dealing > > with the now deprecated org.hibernate.annotations.AccessType annotation. > AFAIK, this annotation used > > to be placed together with other mapping annotations. > > > > So what do we want to discuss here really? > > > > --Hardy > > > > > > > > > > > > > > > > From hardy at hibernate.org Wed Mar 26 15:21:32 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 20:21:32 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <6FB133B2-B049-4B60-9F38-61E219B66B98@hibernate.org> Message-ID: <6FBAD40A-E0D9-4C9D-B70D-F9A1CD20EEB6@hibernate.org> On 26 Jan 2014, at 20:16, Steve Ebersole wrote: > Ok, but... its still a good spring board to discuss this topic which is strangely unclear and murky in terms of what we do and do not support. Sure. I am just saying, we are discussing a wrong test. When I was implementing the JPA @Access rules, I never had the intentions to support the mapping which started the this thread. In my interoperation of the JPA spec it is wrong. It should either thrown an exception (in fact I thought there used to be some checks which would actually do that) or if anything just ignored the annotation. ?Hardy From steve at hibernate.org Wed Mar 26 15:27:08 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 14:27:08 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <6FBAD40A-E0D9-4C9D-B70D-F9A1CD20EEB6@hibernate.org> References: <6FB133B2-B049-4B60-9F38-61E219B66B98@hibernate.org> <6FBAD40A-E0D9-4C9D-B70D-F9A1CD20EEB6@hibernate.org> Message-ID: Well we are in the position we are in already from one person making this determination ;) So that is the situation I am trying to avoid. As this thread is showing, we all have different readings/interpretations of the same spec passages. It is good to come to a consensus. On Wed, Mar 26, 2014 at 2:21 PM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 20:16, Steve Ebersole wrote: > > > Ok, but... its still a good spring board to discuss this topic which is > strangely unclear and murky in terms of what we do and do not support. > > Sure. I am just saying, we are discussing a wrong test. When I was > implementing the JPA @Access rules, I never had the intentions to support > the mapping which started the this thread. In my interoperation of the JPA > spec it is wrong. It should either thrown an exception (in fact I thought > there > used to be some checks which would actually do that) or if anything just > ignored the annotation. > > --Hardy > > > > From emmanuel at hibernate.org Wed Mar 26 15:32:17 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 26 Mar 2014 20:32:17 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> Message-ID: <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> I was under the assumption that the test was as I wrote it but Hardy proved my assumption wrong here and I mixed @Access and @AccessType. On 26 Mar 2014, at 20:14, Steve Ebersole wrote: > So the spec does specifically say "It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)". I understanding making usability choices when the spec is unclear. Do you think there is non-clarity in that quote though? > > Even if you say making usability choices when the spec is very clear, but "wrong"... again I can live with that. But we need to be clear about that. > > > > On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard wrote: > My take on the spec as always been that I'd rather follow the intent, > the common sense above the letter. Likewise, I favored user experience > over spec strict adherence. > I did clash numerous time with the TCK in these targets but I still > prefer that over just doing something stupid but spec to the letter. > (this is general and not specific to that case). > > Anyway so my take is pretty much as it was when I first implemented > @AccessType even if it steps over the spec at the margin. > BTW I'm also happy if we all decide I made a usability mistake that should be fixed. > > Emmanuel > > On Wed 2014-03-26 11:14, Steve Ebersole wrote: > > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole wrote: > > > > > It does violate the spec though, that's the problem: > > > > > > > Well it *could* be read to violate the spec. That's inherently the problem > > with specs that use unclear wording; they can be read and argued multiple > > ways. > > > > > > > > > > > > "... It is not permitted to specify a field as Access(PROPERTY) or a > > > property as Access(FIELD)..." > > > > > > which imo is exactly what this is doing (specifying a property as FIELD): > > > > > > @Id > > > @GeneratedValue > > > @Access(AccessType.FIELD) > > > public long getId() { > > > return id; > > > } > > > > > > > > > > > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero wrote: > > > > > >> I do of course agree that people should use a single strategy and > > >> stick to it, so I agree with your reading about what the "general > > >> expectation" is. > > >> > > >> But the original test represents a quite naturally looking example and > > >> it's hard to justify why that should be considered illegal; I'd > > >> probably be more inclined in making user's life easier than try to > > >> lecture them about how a proper mapping should look like. > > >> > > >> Ignoring any annotation leads to waste of time and debugging > > >> frustration, so rather than silently discarding a mis-positioned > > >> annotation I'd prefer a fail-fast approach; that said I think just > > >> applying them all - as long as there are no obvious conflicting > > >> annotations - would be even more user friendly and doesn't seem to > > >> violate any specific wording of the spec. > > >> > > >> Sanne > > >> > > >> > > >> On 26 March 2014 13:57, Steve Ebersole wrote: > > >> > Again from the spec (still discussing class-level Access(PROPERTY)) : > > >> "The > > >> > behavior is undefined if mapping annotations are placed on any instance > > >> > variables defined by the class for which Access(FIELD) is not > > >> specified". > > >> > > > >> > Which to me implies that the expectation for switching access for a > > >> > particular field within such a class is to annotate the *field* with > > >> > Access(FIELD). > > >> > > > >> > Also the footnote to this sections seems very relevant: > > >> > > > >> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a > > >> > property as Access(FIELD)..." > > >> > > > >> > > > >> > > > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < > > >> emmanuel at hibernate.org> > > >> > wrote: > > >> >> > > >> >> My reading at the time and what I did find more intuitive is what the > > >> >> test represents. > > >> >> > > >> >> Entity level @AccessType expresses where the annotations should > > >> >> be. Otherwise the position of @Id is used to find the access type to > > >> >> consider annotation wise. > > >> >> > > >> >> If for a few attributes I wish to use the alternative property access, > > >> I > > >> >> can add @AccessType next to the other annotations but expressing that > > >> >> the actual property value access is based on the alternative access. > > >> >> That way, all annotations are in the same place. > > >> >> > > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: > > >> >> > As a user I would not expect the @Access annotation to be treated as > > >> a > > >> >> > special case by the framework in terms of when an annotation is > > >> >> > ignored, as for example that I can put this on either properties or > > >> >> > fields, and it would not be ignored, while other annotations could be > > >> >> > ignored depending on the position. > > >> >> > > > >> >> > Also I highly doubt that there is a practical use case to "comment" a > > >> >> > mapping annotation by moving it to the wrong position (say I move a > > >> >> > @GeneratedValue from a field to a property when using FIELD access): > > >> >> > that would be extremely confusing to maintain. > > >> >> > > > >> >> > The spec's wording states "When Access(PROPERTY) is applied to an > > >> >> > [...] mapping annotations **may** be placed on .." > > >> >> > I'd stress that it doesn' t say "must" but "may", and also doesn't > > >> >> > seem to strictly ban the opposite. > > >> >> > > > >> >> > As a user if I put a mapping annotation anywhere I expect it to be > > >> >> > respected, so I would expect the framework to work on the union of > > >> the > > >> >> > possible positions, and probably even to throw an exception on > > >> >> > conflicting options. The @Access property would then only be used to > > >> >> > state which access strategy should be used (and a nice effect is tha > > >> >> > the name becomes particularly self-explanatory too). > > >> >> > > > >> >> > Also there are many types of possible contradictions in the mapping > > >> >> > options: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > Or you could have a stronger conflict which isn't solvable via > > >> >> > AccesType "rules" either: > > >> >> > > > >> >> > public class Course { > > >> >> > @Id @GeneratedValue(strategy=TABLE) > > >> >> > @Access(AccessType.FIELD) > > >> >> > private long id; > > >> >> > ... > > >> >> > > > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) > > >> >> > @Access(AccessType.PROPERTY) > > >> >> > public long getId() { > > >> >> > return id; > > >> >> > } > > >> >> > > > >> >> > This last example is the reason why I think you should always > > >> >> > consistently look at both to collect mapping options, and possibly > > >> >> > throw runtime exceptions. > > >> >> > > > >> >> > Sanne > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 26 March 2014 04:13, Steve Ebersole wrote: > > >> >> > > >From the test > > >> >> > > > > >> >> > > > > >> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride > > >> >> > > we have the following: > > >> >> > > > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test asserts that this is a valid mapping. Granted that the > > >> spec > > >> >> > > is > > >> >> > > very unclear here, so I might be missing something. The pertinent > > >> >> > > spec > > >> >> > > section here states: > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > *When Access(PROPERTY) is applied to an entity class, mapped > > >> >> > > superclass, or embeddableclass, mapping annotations may be placed > > >> on > > >> >> > > the > > >> >> > > properties of that class, and the persistenceprovider runtime > > >> accesses > > >> >> > > persistent state via the properties defined by that class. All > > >> >> > > proper-ties > > >> >> > > that are not annotated with the Transient annotation are > > >> persistent. > > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to > > >> >> > > selectively designate indi-vidual attributes within the class for > > >> >> > > instance > > >> >> > > variable access. To specify a persistent instancevariable for > > >> access > > >> >> > > by the > > >> >> > > persistence provider runtime, that instance variable must be > > >> >> > > desig-nated > > >> >> > > Access(FIELD).* > > >> >> > > > > >> >> > > > > >> >> > > I can see a few different ways to read that: > > >> >> > > > > >> >> > > 1) @Access can be placed on the attribute to define both where to > > >> look > > >> >> > > for > > >> >> > > mapping annotations and the runtime access strategy for a given > > >> >> > > attribute. > > >> >> > > Here, we'd do: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > 2) @Access can be placed on the attribute to define the runtime > > >> access > > >> >> > > strategy for a given attribute, but the class/hierarchy AccessType > > >> >> > > controls > > >> >> > > where to look for mapping annotations. This would lead to: > > >> >> > > > > >> >> > > @Entity > > >> >> > > @Access(AccessType.PROPERTY) > > >> >> > > public class Course3 { > > >> >> > > @Access(AccessType.FIELD) > > >> >> > > private long id; > > >> >> > > ... > > >> >> > > > > >> >> > > @Id > > >> >> > > @GeneratedValue > > >> >> > > public long getId() { > > >> >> > > return id; > > >> >> > > } > > >> >> > > ... > > >> >> > > } > > >> >> > > > > >> >> > > The test seems to illustrate that our legacy code made yet a 3rd > > >> >> > > reading of > > >> >> > > this passage such that @Access is still considered a "mapping > > >> >> > > annotation" > > >> >> > > even though that seems to directly contradict "To specify a > > >> persistent > > >> >> > > instance > > >> >> > > variable for access by the persistence provider runtime, that > > >> instance > > >> >> > > variable must be desig- > > >> >> > > nated Access(FIELD)." > > >> >> > > > > >> >> > > > > >> >> > > Is there some other passage I am missing that bears on what to do > > >> >> > > here? > > >> >> > > How do y'all feel about that passage and its implications on this > > >> >> > > test > > >> >> > > mapping? > > >> >> > > _______________________________________________ > > >> >> > > 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 Mar 26 15:36:41 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 20:36:41 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> Message-ID: <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> On 26 Jan 2014, at 15:56, Sanne Grinovero wrote: > But the original test represents a quite naturally looking example and > it's hard to justify why that should be considered illegal; Because it is against the rules for the placement of @Access. At least in my interpretation of the spec. > Ignoring any annotation leads to waste of time and debugging > frustration, so rather than silently discarding a mis-positioned > annotation I'd prefer a fail-fast approach; True. There are several bug reports due to the fact that we ignore mapping information. However, we never have taken all annotations into consideration. The approach has always been to first determine where to look for annotations (per default based on the placement of the @Id annotation) and then only consider annotations placed according to the discovered strategy. I would assume there were two reasons for ignoring ?wrongly? placed annotations: - annotation processing time and the attempt to avoid accessing all fields and getters via reflection - a considerable extra effort in coding to do proper processing and error handling Personally I could imagine an option where we determine an default annotation placement and throw an exception if any mapping annotation is wrongly placed. If the option is disabled we ignore (maybe log) the annotation. > that said I think just > applying them all - as long as there are no obvious conflicting > annotations - would be even more user friendly and doesn't seem to > violate any specific wording of the spec. -1 ?Hardy From hardy at hibernate.org Wed Mar 26 15:44:58 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 20:44:58 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <20140326125527.GF42990@hibernate.org> References: <20140326125527.GF42990@hibernate.org> Message-ID: <1DA4A006-A8CB-49B2-93E3-7A9FC121A246@hibernate.org> On 26 Jan 2014, at 13:55, Emmanuel Bernard wrote: > I don't have a full grasp of the consequences, I'll need to think about > it. :-) There might be a couple of other package changes which would make sense (unrelated to the split package problem). I guess now is the time to discuss and apply them > Here are a few comments in the mean time. > SearchFactory is not a SPI, it is used by application developers. Sure. Same for SearchException. However, the same applies if we decide to address the problem in the orm module. Also there API classes will move. So one way or the other, developers would need to adjust their code. ?Hardy From sanne at hibernate.org Wed Mar 26 15:52:30 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Mar 2014 19:52:30 +0000 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <20140326125527.GF42990@hibernate.org> References: <20140326125527.GF42990@hibernate.org> Message-ID: It's a though choice. The classes in the ORM module are extremely widely used by our primary target: - FullTextQuery - Search - FullTextSession and two more lesser ones, but I think the 3 above are probably "THE API". To move these out of the way we'd at least need to postpone the OSGi work for after a Beta to include a deprecated version of these. Or we keep them around in the backwards compatible module "hibernate-search" ? Doesn't seem like a piece of cake to be able to actually handle this duplication in our implementation. On the other option, in Engine we have: - Environment (containing all the configuration constants) - ProjectionConstants (more useful constants) - SearchException - SearchFactory (another strong case of public API) Also to remember the changes in Engine also affect the HQL parser (OGM) and Infinispan Query and its users; we can adapt for it but ultimately that's our responsibility too, probably best to verify early on to see the impact. Not really a reason to not do it, but it has an impact on several other projects which we need to facilitate. Now so far I've only tackled the "migration problem", but I guess the goal should be to get to the best outcome in terms of what's more sensible. Emmanuel, could you elaborate of what you have in mind as "scalability reasons"? I think I like Hardy's approach of moving from Engine better; not least we can provide alternative deprecated constants in the ORM module for ORM users to use as a migration help (Environment and ProjectionConstants). To reply on the more fine-grained details: > org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment since it's API, WDYT of a fully fledged mouthfull "org.hibernate.search.configuration.Environment" > org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory as Emmanuel said, that's an API currently. I'm inclined to think we should convert it to an SPI, and provide a richer more ORM specific version in the ORM module? That way, we could keep the package name. It would break things for Infinispan Query API but it seems that would happen anyway. > org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException Maybe making the package plural? We should add variations for specific failures. > org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter "filtering" ? "filters" ? Not too fond of the singular term as it's not very explicit (yes I know it's an existing one). > org.hibernate.search.Version -> org.hibernate.search.engine.Version +1 Cheers, Sanne On 26 March 2014 12:55, Emmanuel Bernard wrote: > I don't have a full grasp of the consequences, I'll need to think about > it. > Here are a few comments in the mean time. > SearchFactory is not a SPI, it is used by application developers. > For scalability reasons, I would be tempted to move the orm module > classes out of the root package. But that is definitely the most > impactful of the two moves. > > Emmanuel > > On Tue 2014-03-25 22:11, Hardy Ferentschik wrote: >> Hi there, >> >> As part of my work for making Search OSGi ready [1], I am looking into addressing HSEARCH-1560 [2] which is about >> split packages which we have between some of our Search bundles (or modules to use Maven lingo). >> >> Basically a split package "is caused where two or more bundles export the same package name and version, usually with different contents?. [3] >> In terms of OSGi, split packages are bad and should be avoided. There exists a work around [3], but afaiu it is frowned upon. >> While working on an integration test trying to run Search in Apache Karaf, I was running into this problem and basically needed (for the time being) >> revert to the mentioned work around. >> >> The biggest for getting rid of split packages is org.hibernate.search which is a split packages between the engine and orm bundle. In org.hibernate.search of engine >> we have: >> - Environment, >> - FullTextFilter, >> - ProjectionConstants, >> - SearchException, >> - SearchFactory >> - Version. >> >> org.hibernate.search of orm contains: >> - FullTextQuery, >> - FullTextSession, >> - FullTextSharedSessionBuilder, >> - MassIndexer >> - Search. >> >> As you can see, these are quite central classes and moving any of them around will break existing code (even though updating just requires >> to change import statements). If we are serious with OSGi we should address this. We always said, that Search 5 is the release where we can break >> API backwards compatibility. So if we want to do this, we should do it now. On the other hand, it is a big change. >> >> I went ahead and tried to refactor org.hibernate.search in engine, applying the following changes: >> >> org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment >> org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory >> org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException >> org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter >> org.hibernate.search.Version -> org.hibernate.search.engine.Version >> >> Some of these changes I actually find quite fitting independently of the split package problem. FullTextFilter seems to have found its true home now >> and Version and Environment don?t seem too bad either. The big change is SearchFactory and .SearchException. >> >> WDYT? Is this package refactoring something worth doing and if so what do you think about the new locations of the classes? Any better suggestions? >> Or do you think the orm bundle should be refactored instead? >> >> You can see the preliminary result here [4]. >> >> ?Hardy >> >> [1] https://hibernate.atlassian.net/browse/HSEARCH-1465 >> [2] https://hibernate.atlassian.net/browse/HSEARCH-1560 >> [3] http://wiki.osgi.org/wiki/Split_Packages >> [4] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-1560 >> _______________________________________________ >> 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 steve at hibernate.org Wed Mar 26 16:07:50 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 15:07:50 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> Message-ID: I also renamed @AccessType (out custom one) to be @AttributeAccessor to better avoid confusion with the JPA names. On Wed, Mar 26, 2014 at 2:32 PM, Emmanuel Bernard wrote: > I was under the assumption that the test was as I wrote it but Hardy > proved my assumption wrong here and I mixed @Access and @AccessType. > > On 26 Mar 2014, at 20:14, Steve Ebersole wrote: > > So the spec does specifically say "It is not permitted to specify a field > as Access(PROPERTY) or a property as Access(FIELD)". I understanding > making usability choices when the spec is unclear. Do you think there is > non-clarity in that quote though? > > Even if you say making usability choices when the spec is very clear, but > "wrong"... again I can live with that. But we need to be clear about that. > > > > On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard > wrote: > >> My take on the spec as always been that I'd rather follow the intent, >> the common sense above the letter. Likewise, I favored user experience >> over spec strict adherence. >> I did clash numerous time with the TCK in these targets but I still >> prefer that over just doing something stupid but spec to the letter. >> (this is general and not specific to that case). >> >> Anyway so my take is pretty much as it was when I first implemented >> @AccessType even if it steps over the spec at the margin. >> BTW I'm also happy if we all decide I made a usability mistake that >> should be fixed. >> >> Emmanuel >> >> On Wed 2014-03-26 11:14, Steve Ebersole wrote: >> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole > >wrote: >> > >> > > It does violate the spec though, that's the problem: >> > > >> > >> > Well it *could* be read to violate the spec. That's inherently the >> problem >> > with specs that use unclear wording; they can be read and argued >> multiple >> > ways. >> > >> > >> > >> > > >> > > "... It is not permitted to specify a field as Access(PROPERTY) or a >> > > property as Access(FIELD)..." >> > > >> > > which imo is exactly what this is doing (specifying a property as >> FIELD): >> > > >> > > @Id >> > > @GeneratedValue >> > > @Access(AccessType.FIELD) >> > > public long getId() { >> > > return id; >> > > } >> > > >> > > >> > > >> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero > >wrote: >> > > >> > >> I do of course agree that people should use a single strategy and >> > >> stick to it, so I agree with your reading about what the "general >> > >> expectation" is. >> > >> >> > >> But the original test represents a quite naturally looking example >> and >> > >> it's hard to justify why that should be considered illegal; I'd >> > >> probably be more inclined in making user's life easier than try to >> > >> lecture them about how a proper mapping should look like. >> > >> >> > >> Ignoring any annotation leads to waste of time and debugging >> > >> frustration, so rather than silently discarding a mis-positioned >> > >> annotation I'd prefer a fail-fast approach; that said I think just >> > >> applying them all - as long as there are no obvious conflicting >> > >> annotations - would be even more user friendly and doesn't seem to >> > >> violate any specific wording of the spec. >> > >> >> > >> Sanne >> > >> >> > >> >> > >> On 26 March 2014 13:57, Steve Ebersole wrote: >> > >> > Again from the spec (still discussing class-level >> Access(PROPERTY)) : >> > >> "The >> > >> > behavior is undefined if mapping annotations are placed on any >> instance >> > >> > variables defined by the class for which Access(FIELD) is not >> > >> specified". >> > >> > >> > >> > Which to me implies that the expectation for switching access for a >> > >> > particular field within such a class is to annotate the *field* >> with >> > >> > Access(FIELD). >> > >> > >> > >> > Also the footnote to this sections seems very relevant: >> > >> > >> > >> > "[8] ... It is not permitted to specify a field as >> Access(PROPERTY) or a >> > >> > property as Access(FIELD)..." >> > >> > >> > >> > >> > >> > >> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard < >> > >> emmanuel at hibernate.org> >> > >> > wrote: >> > >> >> >> > >> >> My reading at the time and what I did find more intuitive is what >> the >> > >> >> test represents. >> > >> >> >> > >> >> Entity level @AccessType expresses where the annotations should >> > >> >> be. Otherwise the position of @Id is used to find the access type >> to >> > >> >> consider annotation wise. >> > >> >> >> > >> >> If for a few attributes I wish to use the alternative property >> access, >> > >> I >> > >> >> can add @AccessType next to the other annotations but expressing >> that >> > >> >> the actual property value access is based on the alternative >> access. >> > >> >> That way, all annotations are in the same place. >> > >> >> >> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote: >> > >> >> > As a user I would not expect the @Access annotation to be >> treated as >> > >> a >> > >> >> > special case by the framework in terms of when an annotation is >> > >> >> > ignored, as for example that I can put this on either >> properties or >> > >> >> > fields, and it would not be ignored, while other annotations >> could be >> > >> >> > ignored depending on the position. >> > >> >> > >> > >> >> > Also I highly doubt that there is a practical use case to >> "comment" a >> > >> >> > mapping annotation by moving it to the wrong position (say I >> move a >> > >> >> > @GeneratedValue from a field to a property when using FIELD >> access): >> > >> >> > that would be extremely confusing to maintain. >> > >> >> > >> > >> >> > The spec's wording states "When Access(PROPERTY) is applied to >> an >> > >> >> > [...] mapping annotations **may** be placed on .." >> > >> >> > I'd stress that it doesn' t say "must" but "may", and also >> doesn't >> > >> >> > seem to strictly ban the opposite. >> > >> >> > >> > >> >> > As a user if I put a mapping annotation anywhere I expect it to >> be >> > >> >> > respected, so I would expect the framework to work on the union >> of >> > >> the >> > >> >> > possible positions, and probably even to throw an exception on >> > >> >> > conflicting options. The @Access property would then only be >> used to >> > >> >> > state which access strategy should be used (and a nice effect >> is tha >> > >> >> > the name becomes particularly self-explanatory too). >> > >> >> > >> > >> >> > Also there are many types of possible contradictions in the >> mapping >> > >> >> > options: >> > >> >> > >> > >> >> > public class Course { >> > >> >> > @Id @GeneratedValue(strategy=TABLE) >> > >> >> > private long id; >> > >> >> > ... >> > >> >> > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > >> >> > public long getId() { >> > >> >> > return id; >> > >> >> > } >> > >> >> > >> > >> >> > Or you could have a stronger conflict which isn't solvable via >> > >> >> > AccesType "rules" either: >> > >> >> > >> > >> >> > public class Course { >> > >> >> > @Id @GeneratedValue(strategy=TABLE) >> > >> >> > @Access(AccessType.FIELD) >> > >> >> > private long id; >> > >> >> > ... >> > >> >> > >> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE) >> > >> >> > @Access(AccessType.PROPERTY) >> > >> >> > public long getId() { >> > >> >> > return id; >> > >> >> > } >> > >> >> > >> > >> >> > This last example is the reason why I think you should always >> > >> >> > consistently look at both to collect mapping options, and >> possibly >> > >> >> > throw runtime exceptions. >> > >> >> > >> > >> >> > Sanne >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > On 26 March 2014 04:13, Steve Ebersole >> wrote: >> > >> >> > > >From the test >> > >> >> > > >> > >> >> > > >> > >> >> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride >> > >> >> > > we have the following: >> > >> >> > > >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > The test asserts that this is a valid mapping. Granted that >> the >> > >> spec >> > >> >> > > is >> > >> >> > > very unclear here, so I might be missing something. The >> pertinent >> > >> >> > > spec >> > >> >> > > section here states: >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > *When Access(PROPERTY) is applied to an entity class, >> mapped >> > >> >> > > superclass, or embeddableclass, mapping annotations may be >> placed >> > >> on >> > >> >> > > the >> > >> >> > > properties of that class, and the persistenceprovider runtime >> > >> accesses >> > >> >> > > persistent state via the properties defined by that class. All >> > >> >> > > proper-ties >> > >> >> > > that are not annotated with the Transient annotation are >> > >> persistent. >> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is >> possible to >> > >> >> > > selectively designate indi-vidual attributes within the class >> for >> > >> >> > > instance >> > >> >> > > variable access. To specify a persistent instancevariable for >> > >> access >> > >> >> > > by the >> > >> >> > > persistence provider runtime, that instance variable must be >> > >> >> > > desig-nated >> > >> >> > > Access(FIELD).* >> > >> >> > > >> > >> >> > > >> > >> >> > > I can see a few different ways to read that: >> > >> >> > > >> > >> >> > > 1) @Access can be placed on the attribute to define both >> where to >> > >> look >> > >> >> > > for >> > >> >> > > mapping annotations and the runtime access strategy for a >> given >> > >> >> > > attribute. >> > >> >> > > Here, we'd do: >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > 2) @Access can be placed on the attribute to define the >> runtime >> > >> access >> > >> >> > > strategy for a given attribute, but the class/hierarchy >> AccessType >> > >> >> > > controls >> > >> >> > > where to look for mapping annotations. This would lead to: >> > >> >> > > >> > >> >> > > @Entity >> > >> >> > > @Access(AccessType.PROPERTY) >> > >> >> > > public class Course3 { >> > >> >> > > @Access(AccessType.FIELD) >> > >> >> > > private long id; >> > >> >> > > ... >> > >> >> > > >> > >> >> > > @Id >> > >> >> > > @GeneratedValue >> > >> >> > > public long getId() { >> > >> >> > > return id; >> > >> >> > > } >> > >> >> > > ... >> > >> >> > > } >> > >> >> > > >> > >> >> > > The test seems to illustrate that our legacy code made yet a >> 3rd >> > >> >> > > reading of >> > >> >> > > this passage such that @Access is still considered a "mapping >> > >> >> > > annotation" >> > >> >> > > even though that seems to directly contradict "To specify a >> > >> persistent >> > >> >> > > instance >> > >> >> > > variable for access by the persistence provider runtime, that >> > >> instance >> > >> >> > > variable must be desig- >> > >> >> > > nated Access(FIELD)." >> > >> >> > > >> > >> >> > > >> > >> >> > > Is there some other passage I am missing that bears on what >> to do >> > >> >> > > here? >> > >> >> > > How do y'all feel about that passage and its implications on >> this >> > >> >> > > test >> > >> >> > > mapping? >> > >> >> > > _______________________________________________ >> > >> >> > > 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 steve at hibernate.org Wed Mar 26 16:09:19 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 15:09:19 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> Message-ID: I really like the general approach you did in metamodel. In fact, even though I heavily refactored most of that package, the way annotated members are found is largely unchanged. But specifically, take Sanne's example. Access(PROPERTY) for the class. Then for one attribute they want field *access* (runtime). How would you see that? Like I said initially, I think there are 2 potentially valid ways to support this. First, @Entity @Access(AccessType.PROPERTY) public class Course3 { @Id @GeneratedValue @Access(AccessType.FIELD) private long id; ... public long getId() { return id; } ... } This approach gives credence to the passage I have been quoting here: "It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)". Second, @Entity @Access(AccessType.PROPERTY) public class Course3 { private long id; ... @Id @GeneratedValue @Access(AccessType.FIELD) public long getId() { return id; } ... } I prefer the first one. On Wed, Mar 26, 2014 at 2:36 PM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 15:56, Sanne Grinovero wrote: > > > But the original test represents a quite naturally looking example and > > it's hard to justify why that should be considered illegal; > > Because it is against the rules for the placement of @Access. > At least in my interpretation of the spec. > > > Ignoring any annotation leads to waste of time and debugging > > frustration, so rather than silently discarding a mis-positioned > > annotation I'd prefer a fail-fast approach; > > True. There are several bug reports due to the fact that we ignore > mapping information. > However, we never have taken all annotations into consideration. The > approach has always > been to first determine where to look for annotations (per default based > on the placement of > the @Id annotation) and then only consider annotations placed according to > the discovered strategy. > > I would assume there were two reasons for ignoring "wrongly" placed > annotations: > - annotation processing time and the attempt to avoid accessing all fields > and getters via reflection > - a considerable extra effort in coding to do proper processing and error > handling > > Personally I could imagine an option where we determine an default > annotation placement and > throw an exception if any mapping annotation is wrongly placed. If the > option is disabled > we ignore (maybe log) the annotation. > > > that said I think just > > applying them all - as long as there are no obvious conflicting > > annotations - would be even more user friendly and doesn't seem to > > violate any specific wording of the spec. > > -1 > > --Hardy From hardy at hibernate.org Wed Mar 26 16:18:54 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 21:18:54 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> Message-ID: <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote: > The classes in the ORM module are extremely widely used by our primary target: > > - FullTextQuery > - Search > - FullTextSession > > and two more lesser ones, but I think the 3 above are probably "THE > API?. That was my thinking as well. > To move these out of the way we'd at least need to postpone the > OSGi work for after a Beta to include a deprecated version of these. ? I don?t get what you are saying here. Deprecate it in an Alpha in order to then move them in a Beta release? That makes no sense what soever to me. My take on this is, that we are dealing with a new major version of Search and that we are still in Alpha phase. If we need to make non backwards compatible changes we should do it now. > Or we keep them around in the backwards compatible module > "hibernate-search? ? For what? Making things even more complicated? > On the other option, in Engine we have: > - Environment (containing all the configuration constants) > - ProjectionConstants (more useful constants) > - SearchException > - SearchFactory (another strong case of public API) > > Also to remember the changes in Engine also affect the HQL parser > (OGM) and Infinispan Query and its users; we can adapt for it but > ultimately that's our responsibility too, probably best to verify > early on to see the impact. Not really a reason to not do it, but it > has an impact on several other projects which we need to facilitate. Mind you, we are talking just about an import statement change. No API or functional change. And yes, our downstream projects would need to adjust. > I think I like Hardy's approach of moving from Engine better; not > least we can provide alternative deprecated constants in the ORM > module for ORM users to use as a migration help (Environment and > ProjectionConstants). ? > To reply on the more fine-grained details: > >> org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment > > since it's API, WDYT of a fully fledged mouthfull > ?org.hibernate.search.configuration.Environment" I like it. In fact I wish cfg would have been called configuration in the first place. Having both, cfg and configuration seems odd to me. In this case I prefer to just use cfg >> org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory > > as Emmanuel said, that's an API currently. Right. I am not 100% happy with this choice either. Mainly moved it there, since we have SearchFactory related classes in there already (not all of which are api either) > I'm inclined to think we > should convert it to an SPI, and provide a richer more ORM specific > version in the ORM module? Interesting. On the other hand, making SearchFactory an spi sounds strange to me. >> org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException > > Maybe making the package plural? We should add variations for specific failures. +1 I was about to suggest that as well >> org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter > > "filtering" ? "filters" ? > Not too fond of the singular term as it's not very explicit (yes I > know it's an existing one). I think I would stick with filter. I guess it comes down to how disruptive we want to be > >> org.hibernate.search.Version -> org.hibernate.search.engine.Version > > +1 :-) ?Hardy From hardy at hibernate.org Wed Mar 26 16:20:34 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 21:20:34 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> Message-ID: <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> On 26 Jan 2014, at 21:07, Steve Ebersole wrote: > I also renamed @AccessType (out custom one) to be @AttributeAccessor to > better avoid confusion with the JPA names. +1 Definitely the better choice From hardy at hibernate.org Wed Mar 26 16:26:18 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 26 Mar 2014 21:26:18 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> Message-ID: <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> On 26 Jan 2014, at 21:09, Steve Ebersole wrote: > I really like the general approach you did in metamodel. In fact, even though I heavily refactored most of that package, the way annotated members are found is largely unchanged. > > But specifically, take Sanne's example. Access(PROPERTY) for the class. Then for one attribute they want field *access* (runtime). How would you see that? Like I said initially, I think there are 2 potentially valid ways to support this. > > First, > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > @Id > @GeneratedValue > @Access(AccessType.FIELD) > private long id; > ... > > public long getId() { > return id; > } > ... > } > > This approach gives credence to the passage I have been quoting here: "It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)". > > > Second, > > @Entity > @Access(AccessType.PROPERTY) > public class Course3 { > private long id; > ... > > @Id > @GeneratedValue > @Access(AccessType.FIELD) > public long getId() { > return id; > } > ... > } > > I prefer the first one. I prefer #1 as well From steve at hibernate.org Wed Mar 26 16:39:52 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 15:39:52 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> Message-ID: One thing I suggested on IRC (because of the awesomely centralized job you did here) was to possibly extract this into a strategy. We could have a legacy one that follows what Emmanuel decided initially, and then another that does what we all agree here as the correct thing moving forward. On Wed, Mar 26, 2014 at 3:26 PM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 21:09, Steve Ebersole wrote: > > > I really like the general approach you did in metamodel. In fact, even > though I heavily refactored most of that package, the way annotated members > are found is largely unchanged. > > > > But specifically, take Sanne's example. Access(PROPERTY) for the class. > Then for one attribute they want field *access* (runtime). How would you > see that? Like I said initially, I think there are 2 potentially valid > ways to support this. > > > > First, > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > private long id; > > ... > > > > public long getId() { > > return id; > > } > > ... > > } > > > > This approach gives credence to the passage I have been quoting here: > "It is not permitted to specify a field as Access(PROPERTY) or a property > as Access(FIELD)". > > > > > > Second, > > > > @Entity > > @Access(AccessType.PROPERTY) > > public class Course3 { > > private long id; > > ... > > > > @Id > > @GeneratedValue > > @Access(AccessType.FIELD) > > public long getId() { > > return id; > > } > > ... > > } > > > > I prefer the first one. > > I prefer #1 as well From steve at hibernate.org Wed Mar 26 17:29:49 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 16:29:49 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> Message-ID: BTW, here is the topical guide I have started for this: https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc On Wed, Mar 26, 2014 at 3:39 PM, Steve Ebersole wrote: > One thing I suggested on IRC (because of the awesomely centralized job you > did here) was to possibly extract this into a strategy. We could have a > legacy one that follows what Emmanuel decided initially, and then another > that does what we all agree here as the correct thing moving forward. > > > On Wed, Mar 26, 2014 at 3:26 PM, Hardy Ferentschik wrote: > >> >> On 26 Jan 2014, at 21:09, Steve Ebersole wrote: >> >> > I really like the general approach you did in metamodel. In fact, even >> though I heavily refactored most of that package, the way annotated members >> are found is largely unchanged. >> > >> > But specifically, take Sanne's example. Access(PROPERTY) for the >> class. Then for one attribute they want field *access* (runtime). How >> would you see that? Like I said initially, I think there are 2 potentially >> valid ways to support this. >> > >> > First, >> > >> > @Entity >> > @Access(AccessType.PROPERTY) >> > public class Course3 { >> > @Id >> > @GeneratedValue >> > @Access(AccessType.FIELD) >> > private long id; >> > ... >> > >> > public long getId() { >> > return id; >> > } >> > ... >> > } >> > >> > This approach gives credence to the passage I have been quoting here: >> "It is not permitted to specify a field as Access(PROPERTY) or a property >> as Access(FIELD)". >> > >> > >> > Second, >> > >> > @Entity >> > @Access(AccessType.PROPERTY) >> > public class Course3 { >> > private long id; >> > ... >> > >> > @Id >> > @GeneratedValue >> > @Access(AccessType.FIELD) >> > public long getId() { >> > return id; >> > } >> > ... >> > } >> > >> > I prefer the first one. >> >> I prefer #1 as well > > > From sanne at hibernate.org Wed Mar 26 18:11:36 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Mar 2014 22:11:36 +0000 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> Message-ID: On 26 March 2014 20:18, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 20:52, Sanne Grinovero wrote: > >> The classes in the ORM module are extremely widely used by our primary target: >> >> - FullTextQuery >> - Search >> - FullTextSession >> >> and two more lesser ones, but I think the 3 above are probably "THE >> API?. > > That was my thinking as well. > >> To move these out of the way we'd at least need to postpone the >> OSGi work for after a Beta to include a deprecated version of these. > > ? I don?t get what you are saying here. Deprecate it in an Alpha in order > to then move them in a Beta release? That makes no sense what soever to me. > My take on this is, that we are dealing with a new major version of Search > and that we are still in Alpha phase. If we need to make non backwards > compatible changes we should do it now. If we need to change public API we have the obvious options: 1# just break the API 2# deprecate the old one I didn't mean that we stricly should do 2#, but we should at least try hard ;-) But *if* we go for 2#, we should keep the deprecated classes around for at least a Beta release, or the effort (of keeping them) is not worth it as I think an Alpha release is not going to inspire enough confidence, or have enough visibility, for us to suggest using it as a migration milestone. Problem is, that if we keep them you might not be able to finish the OSGi issue, as it requires these classes to be removed. Or maybe we can relax this requirement temporarily? I guess the important milestone to aim at is to define the final API? I guess we shouldn't necessarily aim at fully resolving HSEARCH-1465 in a single tag, and if it comes to breaking our APIs I'd prefer we consider alternatives carefully. >> Or we keep them around in the backwards compatible module >> "hibernate-search? ? > > For what? Making things even more complicated? I agree with you: I'm not suggesting we actually do it, I'm listing our options: some I like, some I don't (like this one). You can consider it a rethorical figure which stresses the fact the previous alternative is better. > >> On the other option, in Engine we have: >> - Environment (containing all the configuration constants) >> - ProjectionConstants (more useful constants) >> - SearchException >> - SearchFactory (another strong case of public API) >> >> Also to remember the changes in Engine also affect the HQL parser >> (OGM) and Infinispan Query and its users; we can adapt for it but >> ultimately that's our responsibility too, probably best to verify >> early on to see the impact. Not really a reason to not do it, but it >> has an impact on several other projects which we need to facilitate. > > Mind you, we are talking just about an import statement change. No API > or functional change. And yes, our downstream projects would need to adjust. I get that. Still a nice self-documenting deprecated class is so much easier to handle than an import statement change. >> I think I like Hardy's approach of moving from Engine better; not >> least we can provide alternative deprecated constants in the ORM >> module for ORM users to use as a migration help (Environment and >> ProjectionConstants). > > ? You could make a copy of Environment and ProjectionConstants in the ORM module, and deprecate it to document the new position. Maybe we shouldn't invest too much into backwards compatibility, but since this is a trivial step we should just do it. >> To reply on the more fine-grained details: >> >>> org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment >> >> since it's API, WDYT of a fully fledged mouthfull >> ?org.hibernate.search.configuration.Environment" > > I like it. In fact I wish cfg would have been called configuration in the first place. > Having both, cfg and configuration seems odd to me. In this case I prefer to just > use cfg Same here. I almost suggested to rename all of _cfg_ to _configuration_ but I didn't realize it contained so much public API, so +1 to stick with cfg. >>> org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory >> >> as Emmanuel said, that's an API currently. > > Right. I am not 100% happy with this choice either. Mainly moved it there, since we have SearchFactory > related classes in there already (not all of which are api either) > >> I'm inclined to think we >> should convert it to an SPI, and provide a richer more ORM specific >> version in the ORM module? > > Interesting. On the other hand, making SearchFactory an spi sounds strange to me. I meant conceptually, the integrators don't really need SearchFactory at all: they rely on SearchFactoryIntegrator. In practice Infinispan Query also exposes the SearchFactory as an API but they could expose an alternative definition for the same functional role. If we break this link, we have the added benefit of being able to expose ORM-specific methods on the public API SearchFactory which we would be bundling in the hibernate-search-orm package (rather than engine as it's today). I don't say there is anything that comes to mind urgently needing this, but it seems nice in terms of future flexibility. The tricky part is that today SearchFactoryIntegrator extends SearchFactory, but since SearchFactoryIntegrator needs to say in Engine, it can't depend on SearchFactory. What would you think of breaking this parent-child relation? >From a user's perspective they wouldn't be able to narrow down their SearchFactory to an SearchFactoryIntegrator, but we could provide an unwrap backdoor. I'm actually thinking now that I'd like to make this change, even if we decided to not move the location for SearchFactory: cleans up a bit of the SearchFactoryIntegrator/SearchFactory/SearchFactoryImplementor/SearchFactoryImplementorWithShareableState hierarchy which we have grown over time to accomodate some of these integration needs. > >>> org.hibernate.search.SearchException -> org.hibernate.search.exception.SearchException >> >> Maybe making the package plural? We should add variations for specific failures. > > +1 I was about to suggest that as well ok >>> org.hibernate.search.FullTextFilter -> org.hibernate.search.filter.FullTextFilter >> >> "filtering" ? "filters" ? >> Not too fond of the singular term as it's not very explicit (yes I >> know it's an existing one). > > I think I would stick with filter. I guess it comes down to how disruptive we want to be ok >>> org.hibernate.search.Version -> org.hibernate.search.engine.Version >> >> +1 > > :-) ok :-) Hoping I didn't miss some crucial point, I think we actually have a reasonable plan. Curious now to hear Emmanuel's POV. Downsides summary: we'd be breaking significant public APIs of both Hibernate Search and Infinispan Query, and also some SPIs :-/ The only reason I'm even thinking of this is that actually some of these changes look like reasonable even out of the OSGi requirements scope :-) Sanne From steve at hibernate.org Wed Mar 26 23:29:45 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 26 Mar 2014 22:29:45 -0500 Subject: [hibernate-dev] Metamodel, Jandex and "XML mixins" Message-ID: I was looking into some failures on master in regards to XML overrides for JPA annotations in relation to our friend Access/AccessType. Which got me to thinking... How does the "mixin" code handle defining the target for the AnnotationInstances it creates? Seems to me this code would have really no idea whether to choose the field or the getter as the target. Which is potentially problematic as we are validating the "placement" of these annotations. Strong? Hardy? Maybe we need to look at adding a virtual notion of the attribute as the target in the virtual AnnotationInstance? From steve at hibernate.org Thu Mar 27 01:26:28 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 00:26:28 -0500 Subject: [hibernate-dev] "derived identifier" mapping Message-ID: What's the rational for supporting the following? @Entity class Product { ... } @Entity class Order { ... } @Entity @IdClass(...) class OrderLine { @Id private Order order; @Id private Product product; } Specifically, the declaration of the OrderLine primary key. Why would these not have to be `@Id @ManyToOne`? From guillaume.smet at gmail.com Thu Mar 27 04:17:49 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 27 Mar 2014 09:17:49 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> Message-ID: Hi, My 2 cents as an end user of Search: just move them. It's really not a big deal if it's compilation errors and we just have to reorganize the imports: we clearly see the errors when we upgrade so we can fix them easily. You just put it prominently in the release notes and it's OK. Most of our problems when we upgrade don't come from API changes but from deeply hidden regressions. It's where we spend a lot of time (yeah I have one to diagnose today on a 4.3 -> 4.4 upgrade :)). -- Guillaume From jwhiting at redhat.com Thu Mar 27 05:32:44 2014 From: jwhiting at redhat.com (Jeremy Whiting) Date: Thu, 27 Mar 2014 09:32:44 +0000 Subject: [hibernate-dev] Bytecode enhancement In-Reply-To: References: Message-ID: <5333F03C.2070204@redhat.com> Hi Guillaume, A Maven plugin for build time enhancement of entities is coded up. Not without a few problems along the way. But I think we are there now. Comments are in-lined with your questions. There should be a plugin in the maven repo soon (if not now) using a Mojo and the necessary descriptors declaring dependencies. pull/669 The documentation has a PR waiting to merge showing users how to configure for Ant, Maven or Gradle. Look at https://github.com/hibernate/hibernate-orm/pull/667 for configuration information going into the reference manual. Jeremy On 03/19/2014 04:25 PM, Guillaume Smet wrote: > Hi, > > I took a look at the bytecode enhancement Maven plugin and I also have > this issuehttps://hibernate.atlassian.net/browse/HHH-8833 . > > As far as I can tell the Maven plugin (and I suppose the Gradle plugin > too) doesn't provide any information about the classpath so it's > impossible to use the bytecode enhancement plugin in real life > applications because you obviously have dependencies to other classes. https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-enhance-maven-plugin/hibernate-enhance-maven-plugin.gradle https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-gradle-plugin/hibernate-gradle-plugin.gradle Are there more dependency declarations you needed ? > > Is this something supported or something very experimental? I found > some old posts of Emmanuel discouraging the use of bytecode > enhancement so I'm not sure it's a good idea to invest our time in it? > > Basically, we have a lot of nullable @OneToOne properties and as far > as I understood it, it's supposed to help this case a lot. > > Maybe using something like > http://www.mograblog.com/2010/01/setting-classloader-in-maven-plugin.html > might be a good idea for the Maven plugin? > > Anyway feedback welcome before we invest time in it. > > Thanks. > From guillaume.smet at hibernate.org Thu Mar 27 06:03:27 2014 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 27 Mar 2014 11:03:27 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 Message-ID: Hi, Before 4.4, when you add a @ContainedIn to a property without the corresponding @IndexedEmbedded, they were still added and taken into account in the dependency resolution which was quite useful to declare dependencies between entities without having an explicit @IndexedEmbedded which are useless in some of our cases. Starting with 4.4, they are simply ignored. I've spent some time to understand why and here it is: https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L686 -> you can see that the @Contained is added even if there is no corresponding @IndexedEmbedded In the new code, the @Contained annotation is added in updateDepthProperties which is conditioned by the fact that there is a corresponding @IndexedEmbedded: https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L711 https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L731 https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L755 I'm wondering if it's a desired change or just an overenthusiastic refactoring? We used the old behavior in several projects so we would really like to see it back if it is the latter. And if it's the former, we would like to discuss it :). Thanks for your feedback. -- Guillaume From emmanuel at hibernate.org Thu Mar 27 06:18:14 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 27 Mar 2014 11:18:14 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> Message-ID: <32309BB5-CB1C-400B-B15E-916ABA5CE491@hibernate.org> On 26 Mar 2014, at 20:52, Sanne Grinovero wrote: > Emmanuel, could you elaborate of what you have in mind as "scalability reasons?? Scale as in having more event provider sources (ORM, Infinispan, X, Y, Z). But we could accept that ORM has historical and privileged rights and will keep the root package. > >> org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory > > as Emmanuel said, that's an API currently. I'm inclined to think we > should convert it to an SPI, and provide a richer more ORM specific > version in the ORM module? > That way, we could keep the package name. It would break things for > Infinispan Query API but it seems that would happen anyway. And each event source would need a SearchFactory subinterface + some delegator implementation? Is that your idea? Because SearchFactory contains very useful cross event source methods like retrieving an analyzer, accessing Lucene directly and providing access to the query DSL. That could work. I am a little concerned about documentation. > "You can use SearchFactory but it?s InfinispanSearchFactory or OrmSearchFactory or? depending on what you use Hsearch for? It will make documentation mix and reuse harder. From emmanuel at hibernate.org Thu Mar 27 06:21:39 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 27 Mar 2014 11:21:39 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <32309BB5-CB1C-400B-B15E-916ABA5CE491@hibernate.org> References: <20140326125527.GF42990@hibernate.org> <32309BB5-CB1C-400B-B15E-916ABA5CE491@hibernate.org> Message-ID: <540D2F65-7CF4-4A9E-92D7-245BE5650BE5@hibernate.org> On 27 Mar 2014, at 11:18, Emmanuel Bernard wrote: > >> >>> org.hibernate.search.SearchFactory -> org.hibernate.search.spi.SearchFactory >> >> as Emmanuel said, that's an API currently. I'm inclined to think we >> should convert it to an SPI, and provide a richer more ORM specific >> version in the ORM module? >> That way, we could keep the package name. It would break things for >> Infinispan Query API but it seems that would happen anyway. > > And each event source would need a SearchFactory subinterface + some delegator implementation? Is that your idea? > Because SearchFactory contains very useful cross event source methods like retrieving an analyzer, accessing Lucene directly and providing access to the query DSL. > > That could work. BTW SearchFactory would still remain an API by that factor. - o.h.s.boostrap.SearchFactory - o.h.s.boostrap.CommonSearchFactory From guillaume.smet at gmail.com Thu Mar 27 06:35:55 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 27 Mar 2014 11:35:55 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: Message-ID: FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0) but as we also have @ContainedIn on transient methods, we can't work around it totally. As usual we are committed to work on a test case and fix once we agree it should be fixed. On Thu, Mar 27, 2014 at 11:03 AM, Guillaume Smet wrote: > Hi, > > Before 4.4, when you add a @ContainedIn to a property without the > corresponding @IndexedEmbedded, they were still added and taken into > account in the dependency resolution which was quite useful to declare > dependencies between entities without having an explicit > @IndexedEmbedded which are useless in some of our cases. > > Starting with 4.4, they are simply ignored. > > I've spent some time to understand why and here it is: > https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L686 > > -> you can see that the @Contained is added even if there is no > corresponding @IndexedEmbedded > > In the new code, the @Contained annotation is added in > updateDepthProperties which is conditioned by the fact that there is a > corresponding @IndexedEmbedded: > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L711 > https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L731 > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L755 > > I'm wondering if it's a desired change or just an overenthusiastic refactoring? > > We used the old behavior in several projects so we would really like > to see it back if it is the latter. > > And if it's the former, we would like to discuss it :). > > Thanks for your feedback. > > -- > Guillaume From hardy at hibernate.org Thu Mar 27 06:36:17 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 11:36:17 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> Message-ID: <7D60C9D6-369F-4D01-85F2-C74EBD7F2669@hibernate.org> On 26 Jan 2014, at 22:29, Steve Ebersole wrote: > BTW, here is the topical guide I have started for this: https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc Very good start. Missing the more complicated cases with explicit class leave specified access type and overrides on the attributes, but it for sure helps understanding the whole concepts. Really like the idea of topical guides more and more. I think they are not only valuable for users of ORM, but also for us. They document assumptions/behaviour which help understanding decisions made in the code. ?Hardy From hardy at hibernate.org Thu Mar 27 06:57:53 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 11:57:53 +0100 Subject: [hibernate-dev] Metamodel, Jandex and "XML mixins" In-Reply-To: References: Message-ID: <736E3EA5-905B-4851-A1D7-1FB155FBA071@hibernate.org> On 27 Jan 2014, at 04:29, Steve Ebersole wrote: > I was looking into some failures on master in regards to XML overrides for > JPA annotations in relation to our friend Access/AccessType. Which got me > to thinking... > > How does the "mixin" code handle defining the target for the > AnnotationInstances it creates? AFAIK it needs to look at two things, the ?access? attribute of the persistence unit and the ?access' attribute of the entity node. Based on that it should create an AnnotationInstance with the appropriate AnnotationTarget. Once these pseudo annotation are created the processing of the mapping information is the same as with actual annotation defined on the entities (metadata-complete needs to be handled here as well in a sense that if a xml mapped entity is metadata-complete, existing AnnotationInstances based on actual annotations must be removed). That?s how it should work. However, this was Strong?s baby. Maybe he could shed some more light on this. > Seems to me this code would have really no idea whether to choose the field > or the getter as the target. Which is potentially problematic as we are > validating the "placement" of these annotations. It does, based on the ?access? attribute (see above) ?Hardy From hardy at hibernate.org Thu Mar 27 06:59:43 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 11:59:43 +0100 Subject: [hibernate-dev] "derived identifier" mapping In-Reply-To: References: Message-ID: <9FF1A849-BDE9-4FCF-8DDB-D3E5BED9CC9D@hibernate.org> No idea. I think Emmanuel had a better understanding of the derived identifier logic. On 27 Jan 2014, at 06:26, Steve Ebersole wrote: > What's the rational for supporting the following? > > > @Entity > class Product { > ... > } > > @Entity > class Order { > ... > } > > @Entity > @IdClass(...) > class OrderLine { > @Id > private Order order; > > @Id > private Product product; > } > > Specifically, the declaration of the OrderLine primary key. Why would > these not have to be `@Id @ManyToOne`? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Thu Mar 27 07:40:06 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 12:40:06 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> Message-ID: On 26 Jan 2014, at 23:11, Sanne Grinovero wrote: > On 26 March 2014 20:18, Hardy Ferentschik wrote: >> >> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote: >> >>> The classes in the ORM module are extremely widely used by our primary target: >>> >>> - FullTextQuery >>> - Search >>> - FullTextSession >>> >>> and two more lesser ones, but I think the 3 above are probably "THE >>> API?. >> >> That was my thinking as well. >> >>> To move these out of the way we'd at least need to postpone the >>> OSGi work for after a Beta to include a deprecated version of these. >> >> ? I don?t get what you are saying here. Deprecate it in an Alpha in order >> to then move them in a Beta release? That makes no sense what soever to me. >> My take on this is, that we are dealing with a new major version of Search >> and that we are still in Alpha phase. If we need to make non backwards >> compatible changes we should do it now. > > If we need to change public API we have the obvious options: > 1# just break the API > 2# deprecate the old one > > I didn't mean that we stricly should do 2#, but we should at least try hard ;-) > But *if* we go for 2#, we should keep the deprecated classes around > for at least a Beta release, or the effort (of keeping them) is not > worth it as I think an Alpha release is not going to inspire enough > confidence, or have enough visibility, for us to suggest using it as a > migration milestone. I just don?t get your migration milestone idea. I doubt seriously that many users have the time and resources to gradually upgrade from let?s say a 4.x version to 5.0.0.Alpha1, 5.0.0.Beta1, ? 5.0.0.Final. There might be some early adopters and contributors who are interested in Search, but in most cases I would expect people to wait at least until a CR and then do a direct upgrade. Also you approach seems to me against my understanding of the different release steps towards a Final. I would use the Alpha releases to actually make the breaking changes and getting more stable once we get to Beta. In your approach things would still work in let?s say Beta1, but then get removed for Beta2 or even a CR. For me that?s contradictive. Personally I also the deprecations as a tool to keep backwards compatibility between final releases, not between intermediate releases working towards a final. For me the question is, do we see a future of Search in OSGi and do we want to invest into making Search fully OSGi enabled or not. If so we should just go ahead and resolve these split packages. If we don?t see OSGi as so important we should just add the minimum of metadata information to the artefacts and use the Require-Bundle workaround and be done with it. > Problem is, that if we keep them you might not be able to finish the > OSGi issue, as it requires these classes to be removed. Well, I guess since the alternative classes would exist at the time of deprecation, we would export them from the bundle, ignoring the deprecated ones. > Or maybe we can relax this requirement temporarily? I guess the important > milestone to aim at is to define the final API? What do you mean with define API. For me the API is defined. We are not making changes to the API as such. > I guess we shouldn?t necessarily aim at fully resolving HSEARCH-1465 in a single tag, Not me either. HSEARCH-1465 is the container issue for all OSGi related tasks. HSEARCH-1560 is just one of the sub tasks which imo needs to be resolved in one go. >> Mind you, we are talking just about an import statement change. No API >> or functional change. And yes, our downstream projects would need to adjust. > > I get that. Still a nice self-documenting deprecated class is so much > easier to handle than an import statement change. Except, that deprecations can be ignored. Not that many developers pay careful attention to the build log and depending on how much logging the build does it might just disappear in the noise. So when will the user actually notice the change? When we remove the deprecated class! At some stage the users of Search need to adjust their imports. I?d rather let them handle a couple of compilation failures and be done with it. >>> I think I like Hardy's approach of moving from Engine better; not >>> least we can provide alternative deprecated constants in the ORM >>> module for ORM users to use as a migration help (Environment and >>> ProjectionConstants). >> >> ? > > You could make a copy of Environment and ProjectionConstants in the > ORM module, and deprecate it to document the new position. Maybe we > shouldn't invest too much into backwards compatibility, but since this > is a trivial step we should just do it. -1 >> I like it. In fact I wish cfg would have been called configuration in the first place. >> Having both, cfg and configuration seems odd to me. In this case I prefer to just >> use cfg > > Same here. I almost suggested to rename all of _cfg_ to > _configuration_ but I didn't realize it contained so much public API, > so +1 to stick with cfg. ok > the tricky part is that today SearchFactoryIntegrator extends > SearchFactory, but since SearchFactoryIntegrator needs to say in > Engine, it can't depend on SearchFactory. What would you think of > breaking this parent-child relation? > From a user's perspective they wouldn't be able to narrow down their > SearchFactory to an SearchFactoryIntegrator, but we could provide an > unwrap backdoor. I also think that in general an unwrap is better. +1 for this > some of > these changes look like reasonable even out of the OSGi requirements > scope :-) Right, I also think that some of these changes make sense one way or another. ?Hardy From hardy at hibernate.org Thu Mar 27 07:42:35 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 12:42:35 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> Message-ID: <151D4F49-EF91-41A9-9674-BBFB94B1746E@hibernate.org> On 27 Jan 2014, at 09:17, Guillaume Smet wrote: > It's really not a big deal if it's compilation errors and we just have > to reorganize the imports: we clearly see the errors when we upgrade > so we can fix them easily. You just put it prominently in the release > notes and it's OK. My thinking exactly. > Most of our problems when we upgrade don't come from API changes but > from deeply hidden regressions. It's where we spend a lot of time > (yeah I have one to diagnose today on a 4.3 -> 4.4 upgrade :)). +1 Thinking back to my time as pure Search user or user of any library, handing the move of classes was never a big issue. Maybe a bit annoying, but basically a no brainer. It becomes tricky if the actual API or behaviour changes. ?Hardy From hardy at hibernate.org Thu Mar 27 07:51:45 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 12:51:45 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: Message-ID: On 27 Jan 2014, at 11:03, Guillaume Smet wrote: > Before 4.4, when you add a @ContainedIn to a property without the > corresponding @IndexedEmbedded, they were still added and taken into > account in the dependency resolution which was quite useful to declare > dependencies between entities without having an explicit > @IndexedEmbedded which are useless in some of our cases. What exactly do you mean with "taken into account in the dependency resolution?? Maybe a full example would help here. > I'm wondering if it's a desired change or just an overenthusiastic refactoring? It might be. Still trying to understand what you are saying and the full implications. In particular I am wondering where a @ContainedIn without the matching @indexedEmbedded makes sense. Custom bridges come to mind in this case. Are you using a custom class or field bridge in this case? If not, I don?t understand what purpose the @ContainedIn would fulfil. ?Hardy From hardy at hibernate.org Thu Mar 27 07:52:52 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 12:52:52 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: Message-ID: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> On 27 Jan 2014, at 11:35, Guillaume Smet wrote: > FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0) > but as we also have @ContainedIn on transient methods, we can't work > around it totally. > > As usual we are committed to work on a test case and fix once we agree > it should be fixed. I think an example/test would be awesome. Then we have some concrete example to base our discussion upon. ?Hardy From sanne at hibernate.org Thu Mar 27 07:53:46 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 27 Mar 2014 11:53:46 +0000 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: On 26 March 2014 20:20, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 21:07, Steve Ebersole wrote: > >> I also renamed @AccessType (out custom one) to be @AttributeAccessor to >> better avoid confusion with the JPA names. > > +1 Definitely the better choice I don't argue with that, but the context of my example was "assuming my team has the convention of always putting mappings on properties", so in such a case I'd want to use the second. I really have no strong feeling against how you all think it should be or any spec wording, my only concern is what happens when someone does have a different interpretation or opinion. AFAIK today these are ignored: would be nice to eventually be able to strictly validate (for whatever decison you might take). I think that's important to be taken into consideration while you work on how Jandex reads things: to be able to provide strict validation, you will need to be able to read annotations from both positions. Sanne From davide at hibernate.org Thu Mar 27 08:07:58 2014 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 27 Mar 2014 12:07:58 +0000 Subject: [hibernate-dev] [OGM] Move container integration test to a separate default test cycle In-Reply-To: References: <20140325092522.GA41254@hibernate.org> Message-ID: > My vote goes to #1 as well for the short term. +1 > we need to share the running containers across > modules, or merge the integration tests in a single module per > container. > Not sure how far Maven will be a problem for this I think it would be easier to start and download the containers without using maven and then run the maven build assuming that everything needed is already downloaded and started. On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero wrote: > My vote goes to #1 as well for the short term. > > There also is a third option, which requires some more work but > provides a very nice balance. > A great deal of the slowness of this complex matrix execution can be > addressed to the continuous startup and teardown of services like the > various databases and the datastores. > > Considering that each of those services starts in less than a second, > the problem is not the single startup but literally the compound > effect of the complex matrix: if we started say MongoDB, and CouchDb, > and all others, and all containers at the beginning of the suite, we > could then run matrix tests in a very efficient way, I'd bet we could > keep the full matrix *and* the testsuite under a single minute. The > goal would be to reuse a single WildFly (or EAP) startup to test on > each database; i.e. we need to share the running containers across > modules, or merge the integration tests in a single module per > container. > Not sure how far Maven will be a problem for this. > > For the OGM needs to test on EAP, I just dicussed with Davide (same > office today), and since we'd be testing an old version of EAP > (6.1.0.Alpha1 being the latest in public Maven repositories), our idea > is that this is too old to be useful anyway. We'll set up a profile - > disabled by default - which downloads and tests latest EAP to be used > by the Jenkins instance running at Red Hat. > > Sanne > > > On 25 March 2014 09:25, Emmanuel Bernard wrote: > > This is a follow up on > > > https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092 > > > > We keep piling up new backends, new containers to test and new rules > > checked at build time. A consequence is that it is becoming less and > > less pleasant to work on OGM. > > > > You can see that n version of Naked+WF+EAP+... multiplied by m backends > > simply will make this project horrendously slow to contribute to. > > I imagine n = 3 or 4 and m = 10 in a medium term. > > > > I see two options that would keep us around for a while: > > > > 1. Make the container integration tests only run with a specific option > > activated on the CI. > > 2. Move the container integration tests outside in a different repo > > altogether. > > > > I do prefer 1. > > > > Emmanuel > > _______________________________________________ > > 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 emmanuel at hibernate.org Thu Mar 27 09:17:25 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 27 Mar 2014 14:17:25 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> Message-ID: <20140327131725.GP42990@hibernate.org> On Thu 2014-03-27 12:40, Hardy Ferentschik wrote: > > the tricky part is that today SearchFactoryIntegrator extends > > SearchFactory, but since SearchFactoryIntegrator needs to say in > > Engine, it can't depend on SearchFactory. What would you think of > > breaking this parent-child relation? > > From a user's perspective they wouldn't be able to narrow down their > > SearchFactory to an SearchFactoryIntegrator, but we could provide an > > unwrap backdoor. I am not following you. You no longer want a common SearchFactory interface usable across all event source implementations? From guillaume.smet at gmail.com Thu Mar 27 09:46:20 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 27 Mar 2014 14:46:20 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> Message-ID: Hi Hardy, On Thu, Mar 27, 2014 at 12:52 PM, Hardy Ferentschik wrote: > I think an example/test would be awesome. Then we have some concrete example > to base our discussion upon. I don't think a test would be useful to understand what we do. Here are a few additional information about our business case. The fact is that we have complex business rules which requires us to reindex entities when we change/index one even if they don't have an @IndexedEmbedded relation. You're right about having specific fieldbridges but we also have the case when we want to index the results of a transient method on a dependency of the object. In one of our (many) examples of this usage, we have: ProductModel @ContainedIn Set articles; ProductArticle doesn't have an @IndexedEmbedded annotation on its ProductModel field because we don't use this feature to index it. But when we reindex a ProductModel, we need to reindex the articles. Moreover, an article might have a ShootingBrief and when we change the ProductModel, we also want to reindex the ShootingBriefs of the ProductArticles as they have a field which depends on a ProductModel property. This field is the result of a transient method. Not an @IndexedEmbedded thing. Using @ContainedIn as we do allows us to build a dependency graph of indexing. And this dependency graph exists even if we don't use @IndexedEmbedded but other Search features (FieldBridges, @Field on a transient method...). Note that it worked perfectly until 4.4. I don't know if it's more clear with these information. Feel free to ping me on IRC to discuss it further if needed. -- Guillaume From steve at hibernate.org Thu Mar 27 09:51:16 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 08:51:16 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote: > > I don't argue with that, but the context of my example was "assuming > my team has the convention of always putting mappings on properties", > so in such a case I'd want to use the second. > Like I said, I could really live with either interpretation. The sole reason I lean towards #1 is the idea of consistency. If you start allowing @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different semantic depending on where you find it (class versus attribute). As I am writing the topical guide, I am realizing there are really 3 questions involved here: 1) How do I determine what is (versus is not) a "persistent attribute"? 2) Where do I look for mapping annotations for each persistent attribute? 3) How do I access persistent attribute values at runtime? This is really where we all (and not just us...) have varying opinions. Like you think (1) and (2) should be handled distinctly, whereas the rest of us (iiuc) think that (1) and (2) should be determined via the same logic. Further, you see the (1)/(2) combo as distinct from (3). To you @Access(FIELD) on the getter is fine because of this; there @Access(FIELD) is merely identifying the style of runtime access. Not saying either is right or wrong. I just think it helps to better understand where/why we all agree/disagree. Which ultimately gives us better understanding in these discussions. > I really have no strong feeling against how you all think it should be > or any spec wording, my only concern is what happens when someone does > have a different interpretation or opinion. AFAIK today these are > ignored: would be nice to eventually be able to strictly validate (for > whatever decison you might take). > > I think that's important to be taken into consideration while you work > on how Jandex reads things: to be able to provide strict validation, > you will need to be able to read annotations from both positions. > For sure. This is one of the things metamodel is striving to do better than before in regards to recognizing and warning about misplaced annotations that will be ignored. From steve at hibernate.org Thu Mar 27 09:56:04 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 08:56:04 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: <7D60C9D6-369F-4D01-85F2-C74EBD7F2669@hibernate.org> References: <20140326130216.GG42990@hibernate.org> <4EA1951D-1F49-448D-932C-6C1FD451774E@hibernate.org> <50860563-B46B-4112-92BD-4CDAD2917882@hibernate.org> <7D60C9D6-369F-4D01-85F2-C74EBD7F2669@hibernate.org> Message-ID: On Thu, Mar 27, 2014 at 5:36 AM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 22:29, Steve Ebersole wrote: > > > BTW, here is the topical guide I have started for this: > https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc > > Very good start. Missing the more complicated cases with explicit class > leave specified access type and overrides on the attributes, but it for > sure helps understanding the whole concepts. > Hence the phrase "started" ;) > Really like the idea of topical guides more and more. I think they are not > only valuable for users of ORM, but also for us. They document > assumptions/behaviour which help understanding > decisions made in the code. Definitely. Good documentation/guides are for more than users. They help us as developers understand the expectations and intentions. They act as "organizational memory". And they help us write and debug tests wrt those expectations and intentions. From emmanuel at hibernate.org Thu Mar 27 09:58:41 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 27 Mar 2014 14:58:41 +0100 Subject: [hibernate-dev] "derived identifier" mapping In-Reply-To: <9FF1A849-BDE9-4FCF-8DDB-D3E5BED9CC9D@hibernate.org> References: <9FF1A849-BDE9-4FCF-8DDB-D3E5BED9CC9D@hibernate.org> Message-ID: <20140327135841.GQ42990@hibernate.org> This code is 8 years old so no I did not remember. I did some archeology. The Git migration slots all of that history so I had to fire up svn. svn checkout https://svn.jboss.org/repos/hibernate/annotations/branches/v3_4_0_GA_CP/ svn annotate src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java svn log -r 11058 src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java svn log | grep -C 3 ANN-492 Anyways, it is related to the following: https://hibernate.atlassian.net/browse/HHH-4259 https://hibernate.atlassian.net/browse/ANN-492 https://forum.hibernate.org/viewtopic.php?t=967202&start=0&postdays=0&postorder=asc&highlight= It looks like a combination of the following: - the old code was not able to get the annotation metadata from the entity. It was getting the metadata from the id class. Against the spec but it was a tough bug to fix - Goeffrey had a problem and contributed the test - the test passed a future version of annotations when I applied it - I left it here as coverage On Thu 2014-03-27 11:59, Hardy Ferentschik wrote: > No idea. I think Emmanuel had a better understanding of the derived identifier logic. > > > > On 27 Jan 2014, at 06:26, Steve Ebersole wrote: > > > What's the rational for supporting the following? > > > > > > @Entity > > class Product { > > ... > > } > > > > @Entity > > class Order { > > ... > > } > > > > @Entity > > @IdClass(...) > > class OrderLine { > > @Id > > private Order order; > > > > @Id > > private Product product; > > } > > > > Specifically, the declaration of the OrderLine primary key. Why would > > these not have to be `@Id @ManyToOne`? > > _______________________________________________ > > 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 steve at hibernate.org Thu Mar 27 10:17:47 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 09:17:47 -0500 Subject: [hibernate-dev] "derived identifier" mapping In-Reply-To: <20140327135841.GQ42990@hibernate.org> References: <9FF1A849-BDE9-4FCF-8DDB-D3E5BED9CC9D@hibernate.org> <20140327135841.GQ42990@hibernate.org> Message-ID: So this is another representation of a choice we are having to make quite a bit in 5.0 development... correctness versus "legacy", which has really implications for users. So if users are relying on this Hibernate "feature" of splitting identifier mapping annotations between the entity and the IdClass, their apps would break if we now start supporting this "the correct way". Maybe this is another case where we can log warning for "misplaced" annotations when we see an IdClass with persistence mapping annotations. The spec makes no mention of use cases where an IdClass has mapping annotations, nor do I consider this a "usability feature" from the users perspective (aside from the mentioned compatibility concerns). FWIW, I took these tests and changed the mappings to instead use @Id @ManyToOne on the entity itself. Metamodel understood that perfectly well... On Thu, Mar 27, 2014 at 8:58 AM, Emmanuel Bernard wrote: > This code is 8 years old so no I did not remember. > I did some archeology. The Git migration slots all of that history so I > had to fire up svn. > > svn checkout > https://svn.jboss.org/repos/hibernate/annotations/branches/v3_4_0_GA_CP/ > svn annotate > src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java > svn log -r 11058 > src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java > svn log | grep -C 3 ANN-492 > > Anyways, it is related to the following: > > https://hibernate.atlassian.net/browse/HHH-4259 > https://hibernate.atlassian.net/browse/ANN-492 > > https://forum.hibernate.org/viewtopic.php?t=967202&start=0&postdays=0&postorder=asc&highlight= > > It looks like a combination of the following: > > - the old code was not able to get the annotation metadata from the > entity. It was getting the metadata from the id class. Against the > spec but it was a tough bug to fix > - Goeffrey had a problem and contributed the test > - the test passed a future version of annotations when I applied it > - I left it here as coverage > > On Thu 2014-03-27 11:59, Hardy Ferentschik wrote: > > No idea. I think Emmanuel had a better understanding of the derived > identifier logic. > > > > > > > > On 27 Jan 2014, at 06:26, Steve Ebersole wrote: > > > > > What's the rational for supporting the following? > > > > > > > > > @Entity > > > class Product { > > > ... > > > } > > > > > > @Entity > > > class Order { > > > ... > > > } > > > > > > @Entity > > > @IdClass(...) > > > class OrderLine { > > > @Id > > > private Order order; > > > > > > @Id > > > private Product product; > > > } > > > > > > Specifically, the declaration of the OrderLine primary key. Why would > > > these not have to be `@Id @ManyToOne`? > > > _______________________________________________ > > > 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 steve at hibernate.org Thu Mar 27 10:50:00 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 09:50:00 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: Here is how I phrase this atm in the topical guide: [NOTE] ==== It is important to understand that generally speaking the phrase "access type" refers to a number of concepts: * Determining which fields/methods constitute a persistent attribute. * Indicating where to look for mapping annotations. * How the attribute (its value) is accessed at runtime For the most part, Hibernate treats all 3 as being the same. There are some caveats here, which we will cover as we go along. ==== On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole wrote: > > > > On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote: >> >> I don't argue with that, but the context of my example was "assuming >> my team has the convention of always putting mappings on properties", >> so in such a case I'd want to use the second. >> > > Like I said, I could really live with either interpretation. The sole > reason I lean towards #1 is the idea of consistency. If you start allowing > @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different > semantic depending on where you find it (class versus attribute). > > As I am writing the topical guide, I am realizing there are really 3 > questions involved here: > 1) How do I determine what is (versus is not) a "persistent attribute"? > 2) Where do I look for mapping annotations for each persistent attribute? > 3) How do I access persistent attribute values at runtime? > > This is really where we all (and not just us...) have varying opinions. > Like you think (1) and (2) should be handled distinctly, whereas the rest > of us (iiuc) think that (1) and (2) should be determined via the same logic. > > Further, you see the (1)/(2) combo as distinct from (3). To you > @Access(FIELD) on the getter is fine because of this; there @Access(FIELD) > is merely identifying the style of runtime access. > > Not saying either is right or wrong. I just think it helps to better > understand where/why we all agree/disagree. Which ultimately gives us > better understanding in these discussions. > > > >> I really have no strong feeling against how you all think it should be >> or any spec wording, my only concern is what happens when someone does >> have a different interpretation or opinion. AFAIK today these are >> ignored: would be nice to eventually be able to strictly validate (for >> whatever decison you might take). >> >> I think that's important to be taken into consideration while you work >> on how Jandex reads things: to be able to provide strict validation, >> you will need to be able to read annotations from both positions. >> > > For sure. This is one of the things metamodel is striving to do better > than before in regards to recognizing and warning about misplaced > annotations that will be ignored. > From steve at hibernate.org Thu Mar 27 14:36:50 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 13:36:50 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: Here is what I am trying to decide between in terms of support for this. Mainly this is a usability matter for me. Part of usability is how easily we can explain this so users can understand and use it. To me there are 2 paths to high usability here... == Consistency The first path would be to be consistent in what "access type" means and its implications. For example, to me that would mean at the beginning of this topical guide I can make the following statement truthfully, then to me we have consistency: A persistent attribute is defined as either FIELD or PROPERTY access (in strict JPA sense). FIELD access means that: 1) A persistent attribute is identified by its Class field 2) The mapping annotations for the persistent attribute are located on the Class field 3) At runtime we access the persistent attribute's value directly via the field. PROPERTY access means: 1) A persistent attribute is identified by its JavaBeans-style getter and setter on a Class 2) The mapping annotations for the persistent attribute are located on the Class getter method 3) At runtime we access the persistent attribute's value via the getter/setter methods. >From there its just a matter of rules for "which" wins at the various levels (hierarchy, class, attribute). == ItJustWorks This is more the proposal of Sanne iiuc. Here, "where to look for mapping annotations" is irrelevant; the idea being that we'd look both on the field and the getter and "merge" the metadata. Another implication here is that @Access explicitly identifies how they are accessed at runtime (and I'd assume this in turn drives the recognition of what are the persistent attributes). There is definitely a beauty here in that the rules are again pretty simple to explain and understand. The thing that worries me is the part about "merging" the metadata. Sanne gave some simple examples of where this would possibly be difficult. But there are others, some even more difficult. One that immediately jumps to my mind is "plural" annotations; for example: @ManyToOne @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) private Person person; @ManyToOne @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) public getPerson() { return person; } Is this 4 join-columns? 2? Error? I think at the very least we should be enforcing that the annotations appear consistently (either all on field or all on getter) for a given attribute *if* we were to go this route. On Thu, Mar 27, 2014 at 9:50 AM, Steve Ebersole wrote: > Here is how I phrase this atm in the topical guide: > > > [NOTE] > ==== > It is important to understand that generally speaking the phrase "access > type" refers to a number of concepts: > > * Determining which fields/methods constitute a persistent attribute. > * Indicating where to look for mapping annotations. > * How the attribute (its value) is accessed at runtime > > For the most part, Hibernate treats all 3 as being the same. There are > some caveats here, which we will cover > as we go along. > ==== > > > > On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole wrote: > >> >> >> >> On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote: >>> >>> I don't argue with that, but the context of my example was "assuming >>> my team has the convention of always putting mappings on properties", >>> so in such a case I'd want to use the second. >>> >> >> Like I said, I could really live with either interpretation. The sole >> reason I lean towards #1 is the idea of consistency. If you start allowing >> @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different >> semantic depending on where you find it (class versus attribute). >> >> As I am writing the topical guide, I am realizing there are really 3 >> questions involved here: >> 1) How do I determine what is (versus is not) a "persistent attribute"? >> 2) Where do I look for mapping annotations for each persistent attribute? >> 3) How do I access persistent attribute values at runtime? >> >> This is really where we all (and not just us...) have varying opinions. >> Like you think (1) and (2) should be handled distinctly, whereas the rest >> of us (iiuc) think that (1) and (2) should be determined via the same logic. >> >> Further, you see the (1)/(2) combo as distinct from (3). To you >> @Access(FIELD) on the getter is fine because of this; there @Access(FIELD) >> is merely identifying the style of runtime access. >> >> Not saying either is right or wrong. I just think it helps to better >> understand where/why we all agree/disagree. Which ultimately gives us >> better understanding in these discussions. >> >> >> >>> I really have no strong feeling against how you all think it should be >>> or any spec wording, my only concern is what happens when someone does >>> have a different interpretation or opinion. AFAIK today these are >>> ignored: would be nice to eventually be able to strictly validate (for >>> whatever decison you might take). >>> >>> I think that's important to be taken into consideration while you work >>> on how Jandex reads things: to be able to provide strict validation, >>> you will need to be able to read annotations from both positions. >>> >> >> For sure. This is one of the things metamodel is striving to do better >> than before in regards to recognizing and warning about misplaced >> annotations that will be ignored. >> > > From hardy at hibernate.org Thu Mar 27 14:49:39 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 19:49:39 +0100 Subject: [hibernate-dev] "derived identifier" mapping In-Reply-To: References: <9FF1A849-BDE9-4FCF-8DDB-D3E5BED9CC9D@hibernate.org> <20140327135841.GQ42990@hibernate.org> Message-ID: On 27 Jan 2014, at 15:17, Steve Ebersole wrote: > So this is another representation of a choice we are having to make quite a bit in 5.0 development... correctness versus "legacy", which has really implications for users. So if users are relying on this Hibernate "feature" of splitting identifier mapping annotations between the entity and the IdClass, their apps would break if we now start supporting this "the correct way". > > Maybe this is another case where we can log warning for "misplaced" annotations when we see an IdClass with persistence mapping annotations. +1 > The spec makes no mention of use cases where an IdClass has mapping annotations, nor do I consider this a "usability feature" from the users perspective (aside from the mentioned compatibility concerns). +1 ?Hardy From hardy at hibernate.org Thu Mar 27 15:01:26 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 27 Mar 2014 20:01:26 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: On 27 Jan 2014, at 19:36, Steve Ebersole wrote: > Here is what I am trying to decide between in terms of support for this. Mainly this is a usability matter for me. Part of usability is how easily we can explain this so users can understand and use it. To me there are 2 paths to high usability here... > > > == Consistency > > The first path would be to be consistent in what "access type" means and its implications. For example, to me that would mean at the beginning of this topical guide I can make the following statement truthfully, then to me we have consistency: > > > A persistent attribute is defined as either FIELD or PROPERTY access (in strict JPA sense). FIELD access means that: > 1) A persistent attribute is identified by its Class field > 2) The mapping annotations for the persistent attribute are located on the Class field > 3) At runtime we access the persistent attribute's value directly via the field. > > PROPERTY access means: > 1) A persistent attribute is identified by its JavaBeans-style getter and setter on a Class > 2) The mapping annotations for the persistent attribute are located on the Class getter method > 3) At runtime we access the persistent attribute's value via the getter/setter methods. > > > From there its just a matter of rules for "which" wins at the various levels (hierarchy, class, attribute). My vote goes to consistency. > == ItJustWorks > > This is more the proposal of Sanne iiuc. Here, "where to look for mapping annotations" is irrelevant; the idea being that we'd look both on the field and the getter and "merge" the metadata. Another implication here is that @Access explicitly identifies how they are accessed at runtime (and I'd assume this in turn drives the recognition of what are the persistent attributes). > > There is definitely a beauty here in that the rules are again pretty simple to explain and understand. The thing that worries me is the part about "merging" the metadata. Sanne gave some simple examples of where this would possibly be difficult. But there are others, some even more difficult. One that immediately jumps to my mind is "plural" annotations; for example: > > @ManyToOne > @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) > private Person person; > > @ManyToOne > @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) > public getPerson() { return person; } > > Is this 4 join-columns? 2? Error? > > I think at the very least we should be enforcing that the annotations appear consistently (either all on field or all on getter) for a given attribute *if* we were to go this route. Right, that would be the minimum requirement. From steve at hibernate.org Thu Mar 27 18:54:24 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Mar 2014 17:54:24 -0500 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator Message-ID: This is a bit of a potentially insidious one. Not the best way to start off a discussion, I know :) The premise is this... Until now Hibernate has represented attribute roles using dots. For an attribute named 'department' on the com.acme.Employee entity, the role would be "com.acme.Employee.department". In terms of embeddables, say Employee had an 'address' embedded with its own attributes like 'city'. Then, the full role for 'city' would be "com.acme.Employee.address.city". As you can start to see the dots here are completely indistinguishable in terms of those which define the package/class and those which identify the attribute "path". So one of the things I started playing with in 5 is to replace the separators used in attribute paths to use '#', such that "com.acme.Employee.address.city" would instead be "com.acme.Employee#address#city". This makes the role fully parseable which is actually useful in quite a few situations. And it REALLY helps in things I have just started working on like storing metadata for composites (embeddeds/embeddables) on the SessionFactory, which is the first step in support for some cool new features around embeddables like discriminated inheritance support. However, there is a minor drawback. Like all attributes, collections have a role. Unfortunately the use of '.' in their role Strings leaks into the SPI in terms of locating the CollectionPersisters. So the question is whether to continue with this path of replacing the use of '.' with '#' for attribute path separators. The drawback is unfortunate. The benefit is very nice, but I can't really say it is required atm. Votes? Thoughts? From gbadner at redhat.com Fri Mar 28 01:52:40 2014 From: gbadner at redhat.com (Gail Badner) Date: Fri, 28 Mar 2014 01:52:40 -0400 (EDT) Subject: [hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors In-Reply-To: <908759481.10129294.1395984902335.JavaMail.zimbra@redhat.com> Message-ID: <1312575400.10133909.1395985960277.JavaMail.zimbra@redhat.com> After pulling, I am getting a failure executing :hibernate-core:runAnnotationProcessors. I tried building with --debug and it looks like the hibernate-core/target/generated-src/apt/main is deleted without being re-generated. When hibernate-core is compiled, there are failures because package org.hibernate.hql.internal.antlr does not exist. Anyone have ideas why this is happening? Thanks, Gail From 905604970 at qq.com Fri Mar 28 05:24:41 2014 From: 905604970 at qq.com (=?gb18030?B?x+/RqSC38A==?=) Date: Fri, 28 Mar 2014 17:24:41 +0800 Subject: [hibernate-dev] Welcome to the "hibernate-dev" mailing list (Digest mode) In-Reply-To: References: Message-ID: hello,i am chinese ,so my english is not good ,sorry! i use hibernate orm + jdts.13 connection sqlserver 2008 , and there are a class of User . class User { .... private Blob pictureImg; ...... } when i save user ,i got a problem " net.sourceforge.jtds.jdbc.JtdsPreparedStatement.setBinaryStream(JtdsPreparedStatement.java:1234) ", i know jtds do not implement the method " setBinaryStream" . but i use hibernate 3 ,it's work well, why? has hibernate-release-4.3.4.Final this " bug" ,i hope your reply,thank you From guillaume.smet at gmail.com Fri Mar 28 05:52:12 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 28 Mar 2014 10:52:12 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> Message-ID: Hardy, This one is really a blocker for us as we have to put something into production really soon with 4.4.2 and we can't do it atm. I take the liberty to open a JIRA issue so that I can start working on a PR with a test showing what we do and a fix. While it looks like it was not an intented feature at the time, it's a very useful one so it would be nice to make it work again. I don't think it has any drawbacks to come back to the preexisting behavior. I understand there probably won't be a release of 4.4.x soon (if any) to fix this but, once we agree on the fix, I can deploy something on our internal repo. -- Guillaume On Thu, Mar 27, 2014 at 2:46 PM, Guillaume Smet wrote: > Hi Hardy, > > On Thu, Mar 27, 2014 at 12:52 PM, Hardy Ferentschik wrote: >> I think an example/test would be awesome. Then we have some concrete example >> to base our discussion upon. > > I don't think a test would be useful to understand what we do. Here > are a few additional information about our business case. > > The fact is that we have complex business rules which requires us to > reindex entities when we change/index one even if they don't have an > @IndexedEmbedded relation. > > You're right about having specific fieldbridges but we also have the > case when we want to index the results of a transient method on a > dependency of the object. > > In one of our (many) examples of this usage, we have: > ProductModel > @ContainedIn > Set articles; > > ProductArticle doesn't have an @IndexedEmbedded annotation on its > ProductModel field because we don't use this feature to index it. But > when we reindex a ProductModel, we need to reindex the articles. > > Moreover, an article might have a ShootingBrief and when we change the > ProductModel, we also want to reindex the ShootingBriefs of the > ProductArticles as they have a field which depends on a ProductModel > property. > > This field is the result of a transient method. Not an @IndexedEmbedded thing. > > Using @ContainedIn as we do allows us to build a dependency graph of > indexing. And this dependency graph exists even if we don't use > @IndexedEmbedded but other Search features (FieldBridges, @Field on a > transient method...). > > Note that it worked perfectly until 4.4. > > I don't know if it's more clear with these information. Feel free to > ping me on IRC to discuss it further if needed. > > -- > Guillaume From hardy at hibernate.org Fri Mar 28 06:35:35 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 11:35:35 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> Message-ID: <776E1394-CF46-4DC1-8E34-E4C9416B5D80@hibernate.org> On 27 Jan 2014, at 14:46, Guillaume Smet wrote: > I don't think a test would be useful to understand what we do. Here > are a few additional information about our business case. Not sure. I think it always helps to see the whole picture. > The fact is that we have complex business rules which requires us to > reindex entities when we change/index one even if they don't have an > @IndexedEmbedded relation. It seems to me you were relying on some side effect of ContainedIn. AFAIK @ContainedIn has always been intended to be the counterpart to @IndexedEmbedded, not as a general reindexing trigger. That?s also what the docs imply imo. For me @ContainedIn used in an entity X means, that the entity Y owning the other side of the associations needs reindexing when X changes, because because the index of Y contains embedded fields from X. You seem to see @ContainedIn as a general trigger to reindex the other side of the association no matter what. I kind of see your use case, but if we go down your path, I think we also need to clarify the intention of @ContainedIn > In one of our (many) examples of this usage, we have: > ProductModel > @ContainedIn > Set articles; > > ProductArticle doesn't have an @IndexedEmbedded annotation on its > ProductModel field because we don't use this feature to index it. But > when we reindex a ProductModel, we need to reindex the articles. So how does get information of the changed ProductModel into the ProductArticle? > Moreover, an article might have a ShootingBrief and when we change the > ProductModel, we also want to reindex the ShootingBriefs of the > ProductArticles as they have a field which depends on a ProductModel > property. Hmm, ok. > This field is the result of a transient method. Not an @IndexedEmbedded thing. > > Using @ContainedIn as we do allows us to build a dependency graph of > indexing. And this dependency graph exists even if we don't use > @IndexedEmbedded but other Search features (FieldBridges, @Field on a > transient method?). Ok ?Hardy From hardy at hibernate.org Fri Mar 28 06:44:06 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 11:44:06 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> Message-ID: <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> On 28 Jan 2014, at 10:52, Guillaume Smet wrote: > This one is really a blocker for us as we have to put something into > production really soon with 4.4.2 and we can't do it atm. I take the > liberty to open a JIRA issue so that I can start working on a PR with > a test showing what we do and a fix. Sure > While it looks like it was not an intented feature at the time, it's a > very useful one so it would be nice to make it work again. As said, I don?t think it was and I think I understand your use case by now. There are two things I am wondering about atm: - will this change effect the indexing optimisation code we have in place which tries to skip indexing in cases were the changed entity properties don?t effect the index - how do we clarify the behaviour of ContainedIn in the docs (it is not just the counterpart of @IndexedEmbedded, but a standalone annotation/feature) > I don't > think it has any drawbacks to come back to the preexisting behaviour. Only thing which comes to mind is this indexing optimisation part, but it might not even be effected. > I understand there probably won't be a release of 4.4.x soon (if any) > to fix this but, once we agree on the fix, I can deploy something on > our internal repo. Ok. ?Hardy From emmanuel at hibernate.org Fri Mar 28 07:16:19 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 28 Mar 2014 12:16:19 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> Message-ID: <20140328111619.GA61492@hibernate.org> We could use either a different annotation or a flag @ContainedIn(someVerySmartName=SomeVerySmartValue) On Fri 2014-03-28 11:44, Hardy Ferentschik wrote: > > On 28 Jan 2014, at 10:52, Guillaume Smet wrote: > > > This one is really a blocker for us as we have to put something into > > production really soon with 4.4.2 and we can't do it atm. I take the > > liberty to open a JIRA issue so that I can start working on a PR with > > a test showing what we do and a fix. > > Sure > > > While it looks like it was not an intented feature at the time, it's a > > very useful one so it would be nice to make it work again. > > As said, I don?t think it was and I think I understand your use case by now. > There are two things I am wondering about atm: > > - will this change effect the indexing optimisation code we have in place which > tries to skip indexing in cases were the changed entity properties don?t effect > the index > - how do we clarify the behaviour of ContainedIn in the docs (it is not just the > counterpart of @IndexedEmbedded, but a standalone annotation/feature) > > > I don't > > think it has any drawbacks to come back to the preexisting behaviour. > > Only thing which comes to mind is this indexing optimisation part, but it might not > even be effected. > > > I understand there probably won't be a release of 4.4.x soon (if any) > > to fix this but, once we agree on the fix, I can deploy something on > > our internal repo. > > Ok. > > ?Hardy > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Mar 28 07:22:35 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 06:22:35 -0500 Subject: [hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors In-Reply-To: <1312575400.10133909.1395985960277.JavaMail.zimbra@redhat.com> References: <908759481.10129294.1395984902335.JavaMail.zimbra@redhat.com> <1312575400.10133909.1395985960277.JavaMail.zimbra@redhat.com> Message-ID: Nope, but this would local to your system. It works for me and it is working in CI On Fri, Mar 28, 2014 at 12:52 AM, Gail Badner wrote: > After pulling, I am getting a failure executing > :hibernate-core:runAnnotationProcessors. > > I tried building with --debug and it looks like the > hibernate-core/target/generated-src/apt/main is deleted without being > re-generated. When hibernate-core is compiled, there are failures because > package org.hibernate.hql.internal.antlr does not exist. > > Anyone have ideas why this is happening? > > Thanks, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Fri Mar 28 07:37:28 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 12:37:28 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: <20140328111619.GA61492@hibernate.org> References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> <20140328111619.GA61492@hibernate.org> Message-ID: <5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org> On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote: > We could use either a different annotation or a flag > > @ContainedIn(someVerySmartName=SomeVerySmartValue) I was also wondering whether a whole new annotation would make sense, but nothing intuitive came to mind right away. I guess @ContainedIn cold work. It is just that we need to make clear what it means and how it behaves. ?Hardy From hardy at hibernate.org Fri Mar 28 07:41:30 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 12:41:30 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <20140327131725.GP42990@hibernate.org> References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> <20140327131725.GP42990@hibernate.org> Message-ID: <0F6F7795-82E6-4746-B8D5-C04A050D0F4B@hibernate.org> Have we by now reached a consensus on wether or not to address the package split? Anyone against generally against it? ?Hardy On 27 Jan 2014, at 14:17, Emmanuel Bernard wrote: > On Thu 2014-03-27 12:40, Hardy Ferentschik wrote: >>> the tricky part is that today SearchFactoryIntegrator extends >>> SearchFactory, but since SearchFactoryIntegrator needs to say in >>> Engine, it can't depend on SearchFactory. What would you think of >>> breaking this parent-child relation? >>> From a user's perspective they wouldn't be able to narrow down their >>> SearchFactory to an SearchFactoryIntegrator, but we could provide an >>> unwrap backdoor. > > I am not following you. You no longer want a common SearchFactory > interface usable across all event source implementations? From steve at hibernate.org Fri Mar 28 07:47:31 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 06:47:31 -0500 Subject: [hibernate-dev] Tests asserting warnings get logged Message-ID: I again have in mind adding some test assertions that a particular logging (WARN) message gets triggered. We have already one such test in place, which is one of the places where our usage of byteman comes in. Given the problems using byteman is causing in CI and the fact that our reliance on it is pretty light at the moment, I wanted to reach out for some other ideas/proposals for ways to handle this testing requirement. I will also reach out to David and James to see if this is something JBoss Logging itself could help us tackle; maybe there is some feature there already that would help. Any other ideas/proposals? From sanne at hibernate.org Fri Mar 28 07:56:45 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Mar 2014 11:56:45 +0000 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: <5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org> References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> <20140328111619.GA61492@hibernate.org> <5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org> Message-ID: On 28 March 2014 11:37, Hardy Ferentschik wrote: > > On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote: > >> We could use either a different annotation or a flag >> >> @ContainedIn(someVerySmartName=SomeVerySmartValue) > > I was also wondering whether a whole new annotation would make sense, but nothing intuitive > came to mind right away. I guess @ContainedIn cold work. It is just that we need to make clear > what it means and how it behaves. +1 Since 4.4 is the last one supporting a wide an popular range of Hibernate versions and application server versions, it's totally possible that we'll be making more bugifx releases if the need shows up. However - I might not have fully grasped this yet - but I'm thinking that this is a feature request and not a bugfix that should be hastily applied on 4.4. Guillaume, I suspect you might be a happier user if you would keep using a more bleeding edge version, so to catch any such thing earlier rather than the day before you go in production. I can only promise you that the migration to 5.0 will be a nightmare if you don't follow along in small iterations :-( Sanne > > ?Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Mar 28 08:03:30 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Mar 2014 12:03:30 +0000 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: Message-ID: I had the same thoughts recently! My idea would be to have a Logger implementation which logs into an in-memory buffer, which you can lookup somehow. For my own test needs, even a static accessor would do. It could be a simple text representation, or it could store a smarter event-list with some assertion helper methods. A reset() method to be invoked at the end of each test (or between tests as needed). I'd then remove Log4J from our test dependencies to primarily rely on assertions only; or for debugging purposes to have it forwards messages to System.out too - probably enabled by some environment option - would be good enough. On 28 March 2014 11:47, Steve Ebersole wrote: > I again have in mind adding some test assertions that a particular logging > (WARN) message gets triggered. We have already one such test in place, > which is one of the places where our usage of byteman comes in. > > Given the problems using byteman is causing in CI and the fact that our > reliance on it is pretty light at the moment, I wanted to reach out for > some other ideas/proposals for ways to handle this testing requirement. I > will also reach out to David and James to see if this is something JBoss > Logging itself could help us tackle; maybe there is some feature there > already that would help. Any other ideas/proposals? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Fri Mar 28 08:06:02 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 13:06:02 +0100 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: <46F2DDEB-3C7B-4C38-8CF4-F92A390B6E48@hibernate.org> On 27 Jan 2014, at 23:54, Steve Ebersole wrote: > This is a bit of a potentially insidious one. Not the best way to start > off a discussion, I know :) > > The premise is this... Until now Hibernate has represented attribute roles > using dots. For an attribute named 'department' on the com.acme.Employee > entity, the role would be "com.acme.Employee.department". In terms of > embeddables, say Employee had an 'address' embedded with its own attributes > like 'city'. Then, the full role for 'city' would be > "com.acme.Employee.address.city". > > As you can start to see the dots here are completely indistinguishable in > terms of those which define the package/class and those which identify the > attribute "path". > > So one of the things I started playing with in 5 is to replace the > separators used in attribute paths to use '#', such that > "com.acme.Employee.address.city" would instead be > "com.acme.Employee#address#city". This makes the role fully parseable > which is actually useful in quite a few situations. And it REALLY helps in > things I have just started working on like storing metadata for composites > (embeddeds/embeddables) on the SessionFactory, which is the first step in > support for some cool new features around embeddables like discriminated > inheritance support. > > However, there is a minor drawback. Like all attributes, collections have > a role. Unfortunately the use of '.' in their role Strings leaks into the > SPI in terms of locating the CollectionPersisters. Which SPI exactly? > So the question is whether to continue with this path of replacing the use > of '.' with '#' for attribute path separators. The drawback is > unfortunate. The benefit is very nice, but I can't really say it is > required atm. > > Votes? Thoughts? I like it. I have been wishing more than once that there would be a clearer distinction. As you say, some existing code is very fugly due to the existing dot notation. ?Hardy From steve at hibernate.org Fri Mar 28 08:14:03 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 07:14:03 -0500 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: <46F2DDEB-3C7B-4C38-8CF4-F92A390B6E48@hibernate.org> References: <46F2DDEB-3C7B-4C38-8CF4-F92A390B6E48@hibernate.org> Message-ID: On Fri, Mar 28, 2014 at 7:06 AM, Hardy Ferentschik wrote: > > On 27 Jan 2014, at 23:54, Steve Ebersole wrote: > > > This is a bit of a potentially insidious one. Not the best way to start > > off a discussion, I know :) > > > > The premise is this... Until now Hibernate has represented attribute > roles > > using dots. For an attribute named 'department' on the com.acme.Employee > > entity, the role would be "com.acme.Employee.department". In terms of > > embeddables, say Employee had an 'address' embedded with its own > attributes > > like 'city'. Then, the full role for 'city' would be > > "com.acme.Employee.address.city". > > > > As you can start to see the dots here are completely indistinguishable in > > terms of those which define the package/class and those which identify > the > > attribute "path". > > > > So one of the things I started playing with in 5 is to replace the > > separators used in attribute paths to use '#', such that > > "com.acme.Employee.address.city" would instead be > > "com.acme.Employee#address#city". This makes the role fully parseable > > which is actually useful in quite a few situations. And it REALLY helps > in > > things I have just started working on like storing metadata for > composites > > (embeddeds/embeddables) on the SessionFactory, which is the first step in > > support for some cool new features around embeddables like discriminated > > inheritance support. > > > > However, there is a minor drawback. Like all attributes, collections > have > > a role. Unfortunately the use of '.' in their role Strings leaks into > the > > SPI in terms of locating the CollectionPersisters. > > Which SPI exactly? > org.hibernate.engine.spi.SessionFactoryImplementor#getCollectionPersister(String role) > So the question is whether to continue with this path of replacing the use > > of '.' with '#' for attribute path separators. The drawback is > > unfortunate. The benefit is very nice, but I can't really say it is > > required atm. > > > > Votes? Thoughts? > > I like it. I have been wishing more than once that there would be a > clearer distinction. > As you say, some existing code is very fugly due to the existing dot > notation. > Even better, internally I have now Object-ified the notion of path and role: AttributePath and AttributeRole. From hardy at hibernate.org Fri Mar 28 08:15:43 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 13:15:43 +0100 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: Message-ID: <0A1D0ACA-A309-4176-A78C-386BAF2E2A5F@hibernate.org> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote: > I'd then remove Log4J from our test dependencies to primarily rely on > assertions only; Why would you do that? I would expect whatever solution we come up with to just delegate to the underlying logger. > or for debugging purposes to have it forwards > messages to System.out too - probably enabled by some environment > option - would be good enough. We have the logging system configurable already. Why complicating things. All we would be after is a way to verify that a given log message gets called. Everything else should behave as before. ?Hardy From hardy at hibernate.org Fri Mar 28 08:16:17 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 13:16:17 +0100 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: <46F2DDEB-3C7B-4C38-8CF4-F92A390B6E48@hibernate.org> Message-ID: <2F79F435-D385-400B-B932-562CD28C3916@hibernate.org> > Even better, internally I have now Object-ified the notion of path and role: AttributePath and AttributeRole. +100 From sanne at hibernate.org Fri Mar 28 08:21:48 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Mar 2014 12:21:48 +0000 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: <0A1D0ACA-A309-4176-A78C-386BAF2E2A5F@hibernate.org> References: <0A1D0ACA-A309-4176-A78C-386BAF2E2A5F@hibernate.org> Message-ID: On 28 March 2014 12:15, Hardy Ferentschik wrote: > > On 28 Jan 2014, at 13:03, Sanne Grinovero wrote: > >> I'd then remove Log4J from our test dependencies to primarily rely on >> assertions only; > > Why would you do that? I would expect whatever solution we come up with to > just delegate to the underlying logger. Exactly, which doesn't need to be Log4J but could be our testable surrogate. > >> or for debugging purposes to have it forwards >> messages to System.out too - probably enabled by some environment >> option - would be good enough. > > We have the logging system configurable already. Why complicating things. > All we would be after is a way to verify that a given log message gets called. > Everything else should behave as before. How so "complicating things"? I'm just suggesting to throw away a lot of unnecessary complexity and focus on the stuff that matters: assert for specific messages, which is something Log4J doesn't provide. So we don't need it, and I don't need it to be configurable either, as long as I can have a single switch to potentially help with debugging. > > ?Hardy > > > From hardy at hibernate.org Fri Mar 28 08:27:30 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 13:27:30 +0100 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: Message-ID: <00C0D461-6F6F-472B-826F-F09E6BFF51B7@hibernate.org> On 28 Jan 2014, at 12:47, Steve Ebersole wrote: > Given the problems using byteman is causing in CI What problem is that? > and the fact that our > reliance on it is pretty light at the moment, I wanted to reach out for > some other ideas/proposals for ways to handle this testing requirement. The problem could be solved by a dynamic proxy. The proxy could be the middle man between the test (adding some test helpers and assertions) and the actual Log implementation. Writing such a proxy should be straight forward, the problem is that afaik there is not way in JBoss Logging to change the Log Implementation. Logger.getMessageLogger just uses the name of the specified Log type and appends ?$logger? and tries to load from the classpath. > I will also reach out to David and James to see if this is something JBoss > Logging itself could help us tackle; maybe there is some feature there > already that would help. Any other ideas/proposals? If they would add a way to specify a custom Log impl (e.g. via a system property) things would become much easier. ?Hardy From guillaume.smet at gmail.com Fri Mar 28 08:28:18 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 28 Mar 2014 13:28:18 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> <20140328111619.GA61492@hibernate.org> <5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org> Message-ID: Hi Sanne, On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero wrote: > However - I might not have fully grasped this yet - but I'm thinking > that this is a feature request and not a bugfix that should be hastily > applied on 4.4. It's not a feature request. 4.4 changed this behavior. It was working well with 4.3 (and every other versions before that). > Guillaume, I suspect you might be a happier user if you would keep > using a more bleeding edge version, so to catch any such thing earlier > rather than the day before you go in production. I can only promise > you that the migration to 5.0 will be a nightmare if you don't follow > along in small iterations :-( I don't think we can be more bleeding edge than us. We upgrade our core framework to new versions as soon as they are released (we coded https://www.artifact-listener.org/ for this purpose). That's why we spend a considerable amount of time doing QA on the components we use - you see a part of this work on ORM + Search but we also do it for other components. You might have noticed that we are often the first company out there to catch regressions. When we have the ability to dedicate cycles to it, we also test CR. But... we develop a lot of applications for a lot of customers and they have different lifecycles: we can upgrade some easily and for others we have to wait for the right opportunity to do it. All in all, we have the following policy: - all the applications in development: they use the latest versions of each components, except if we catch a regression when upgrading. If so we try to help fix it for the next version and we upgrade ASAP; - the applications in production are updated regularly for minor changes; If the changes are big, we wait for our customers to ask changes on the app and we do it then. The fact is that we caught this one while upgrading an app which was using 4.3.0.Final (which is not that old) but I think we have other applications already upgraded to 4.4.2 which have that bug, it's just that we haven't caught it when we upgraded. FWIW, we couldn't upgrade to 4.4.x before 4.4.2.Final because of a few regressions we reported and helped getting fixed (I have at least these ones in mind: HSEARCH-1442 and HSEARCH-1462 but IIRC we had others). (Sorry for the noise but I thought it was a good opportunity to explain how we work, considering we're involved in this community for quite a long time now) -- Guillaume From hardy at hibernate.org Fri Mar 28 08:35:47 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 28 Mar 2014 13:35:47 +0100 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: <0A1D0ACA-A309-4176-A78C-386BAF2E2A5F@hibernate.org> Message-ID: On 28 Jan 2014, at 13:21, Sanne Grinovero wrote: > On 28 March 2014 12:15, Hardy Ferentschik wrote: >> >> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote: >> >>> I'd then remove Log4J from our test dependencies to primarily rely on >>> assertions only; >> >> Why would you do that? I would expect whatever solution we come up with to >> just delegate to the underlying logger. > > Exactly, which doesn't need to be Log4J but could be our testable surrogate. Except with log4j I already have a lot of built-in functionality which you would have to first build in your solution. For example, category configuration or the ability to use different appenders. >>> or for debugging purposes to have it forwards >>> messages to System.out too - probably enabled by some environment >>> option - would be good enough. >> >> We have the logging system configurable already. Why complicating things. >> All we would be after is a way to verify that a given log message gets called. >> Everything else should behave as before. > > How so "complicating things"? I'm just suggesting to throw away a lot > of unnecessary complexity Which unnecessary complexity? > and focus on the stuff that matters: assert for specific messages, The ability to assert log messages is great and wanted, but the overall log is important as well. I want to see that it actually works. And just looking at the log every now and then helps me to understand what?s happening, detect potential typos, find places where logging should be improved, ... > which is something Log4J doesn't provide Why would it, it is not a testing framework. ?Hardy From steve at hibernate.org Fri Mar 28 08:55:23 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 07:55:23 -0500 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: <00C0D461-6F6F-472B-826F-F09E6BFF51B7@hibernate.org> References: <00C0D461-6F6F-472B-826F-F09E6BFF51B7@hibernate.org> Message-ID: On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote: > > > On 28 Jan 2014, at 12:47, Steve Ebersole wrote: > > > Given the problems using byteman is causing in CI > > What problem is that? Port contention of some sort > > > and the fact that our > > reliance on it is pretty light at the moment, I wanted to reach out for > > some other ideas/proposals for ways to handle this testing requirement. > > The problem could be solved by a dynamic proxy. The proxy could > be the middle man between the test (adding some test helpers and assertions) and the actual Log implementation. > Writing such a proxy should be straight forward, the problem is that afaik there is not way > in JBoss Logging to change the Log Implementation. Logger.getMessageLogger just uses the name of the specified Log type > and appends '$logger' and tries to load from the classpath. > > > I will also reach out to David and James to see if this is something JBoss > > Logging itself could help us tackle; maybe there is some feature there > > already that would help. Any other ideas/proposals? > > If they would add a way to specify a custom Log impl (e.g. via a system property) things would become much easier. They do. But the only one I know of to easily swap is the backend, which is maybe to "low", at that point you'd just be getting warn(...) or debug(...) calls. Ideally I'd like to see a way to intercept the MessageLogger calls From sanne at hibernate.org Fri Mar 28 09:10:15 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Mar 2014 13:10:15 +0000 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: <0A1D0ACA-A309-4176-A78C-386BAF2E2A5F@hibernate.org> Message-ID: On 28 March 2014 12:35, Hardy Ferentschik wrote: > > On 28 Jan 2014, at 13:21, Sanne Grinovero wrote: > >> On 28 March 2014 12:15, Hardy Ferentschik wrote: >>> >>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote: >>> >>>> I'd then remove Log4J from our test dependencies to primarily rely on >>>> assertions only; >>> >>> Why would you do that? I would expect whatever solution we come up with to >>> just delegate to the underlying logger. >> >> Exactly, which doesn't need to be Log4J but could be our testable surrogate. > > Except with log4j I already have a lot of built-in functionality which you would have > to first build in your solution. For example, category configuration or the ability to > use different appenders. > >>>> or for debugging purposes to have it forwards >>>> messages to System.out too - probably enabled by some environment >>>> option - would be good enough. >>> >>> We have the logging system configurable already. Why complicating things. >>> All we would be after is a way to verify that a given log message gets called. >>> Everything else should behave as before. >> >> How so "complicating things"? I'm just suggesting to throw away a lot >> of unnecessary complexity > > Which unnecessary complexity? > >> and focus on the stuff that matters: assert for specific messages, > > The ability to assert log messages is great and wanted, but the overall log > is important as well. I want to see that it actually works. But that's not related to our needs in unit tests, if any we should avoid to test third party libraries which aren't required. > And just looking at the log > every now and then helps me to understand what?s happening, detect potential typos, > find places where logging should be improved, ... Ok you have a point there on the experience, but I'm focusing on my needs in unit tests, while you' re talking about end to end integration tests. We probably need both, but that complicates things as if you have two logger implementations I'm not sure we can pick which one JBoss Logger would bind to. Generally I think we have lots to improve in isolating our unit test to be quicker and less dependent on stuff which is unrelated to their test subject; i.e. we should work to get more "pure" unit tests, and parsing an external log file generated by an optional library to test for e warn method to be triggered is going in the opposite direction. > >> which is something Log4J doesn't provide > > Why would it, it is not a testing framework. > > ?Hardy > From guillaume.smet at gmail.com Fri Mar 28 09:32:17 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 28 Mar 2014 14:32:17 +0100 Subject: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4 In-Reply-To: References: <89310918-F608-473D-A0DF-08A2736F68F7@hibernate.org> <0F09FD86-F2EB-4336-A267-070A9FA388A2@hibernate.org> <20140328111619.GA61492@hibernate.org> <5EDB4368-A648-4CC3-A64E-6F809632D817@hibernate.org> Message-ID: Hi again, I posted a pull request for the 4.5 branch: https://github.com/hibernate/hibernate-search/pull/590 . Comments welcome! I included a rather large test case I have extracted from our app. It's simplified but I think you should get the idea by looking at it. All tests passes. FWIW, I find the new way to do it more consistent with the names of the methods as updateContainedInMaxDepths now does exactly what its name says. It would be nice if it could also be backported to 4.4.x. Glad to discuss further enhancements if needed but I think the old behavior should be brought back before considering any further enhancements/features. -- Guillaume On Fri, Mar 28, 2014 at 1:28 PM, Guillaume Smet wrote: > Hi Sanne, > > On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero wrote: >> However - I might not have fully grasped this yet - but I'm thinking >> that this is a feature request and not a bugfix that should be hastily >> applied on 4.4. > > It's not a feature request. 4.4 changed this behavior. It was working > well with 4.3 (and every other versions before that). > >> Guillaume, I suspect you might be a happier user if you would keep >> using a more bleeding edge version, so to catch any such thing earlier >> rather than the day before you go in production. I can only promise >> you that the migration to 5.0 will be a nightmare if you don't follow >> along in small iterations :-( > > I don't think we can be more bleeding edge than us. We upgrade our > core framework to new versions as soon as they are released (we coded > https://www.artifact-listener.org/ for this purpose). That's why we > spend a considerable amount of time doing QA on the components we use > - you see a part of this work on ORM + Search but we also do it for > other components. You might have noticed that we are often the first > company out there to catch regressions. > > When we have the ability to dedicate cycles to it, we also test CR. > > But... we develop a lot of applications for a lot of customers and > they have different lifecycles: we can upgrade some easily and for > others we have to wait for the right opportunity to do it. > > All in all, we have the following policy: > - all the applications in development: they use the latest versions of > each components, except if we catch a regression when upgrading. If so > we try to help fix it for the next version and we upgrade ASAP; > - the applications in production are updated regularly for minor > changes; If the changes are big, we wait for our customers to ask > changes on the app and we do it then. > > The fact is that we caught this one while upgrading an app which was > using 4.3.0.Final (which is not that old) but I think we have other > applications already upgraded to 4.4.2 which have that bug, it's just > that we haven't caught it when we upgraded. > > FWIW, we couldn't upgrade to 4.4.x before 4.4.2.Final because of a few > regressions we reported and helped getting fixed (I have at least > these ones in mind: HSEARCH-1442 and HSEARCH-1462 but IIRC we had > others). > > (Sorry for the noise but I thought it was a good opportunity to > explain how we work, considering we're involved in this community for > quite a long time now) > > -- > Guillaume From guillaume.smet at gmail.com Fri Mar 28 09:55:18 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 28 Mar 2014 14:55:18 +0100 Subject: [hibernate-dev] Fix for the Eclipse formatter Message-ID: Hi, Here is a fix for the Eclipse formatter posted on the community site. Currently, it changes: x.foo(); to x. foo(); which doesn't respect the checkstyle rules. Thought it might be useful to report it as it's quite painful to have a build broken because of that. Thanks! -- Guillaume From emmanuel at hibernate.org Fri Mar 28 14:40:16 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 28 Mar 2014 19:40:16 +0100 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: Message-ID: <1F35AB5A-CE54-4C9C-A5EA-2EB525FAA74E@hibernate.org> XWiki solved that with a JUnit rule and an in-memory log appender. I beleive their test adds the log appender programmatically during the tests. https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-test/xwiki-commons-test-simple/src/main/java/org/xwiki/test/LogRule.java On 28 Mar 2014, at 13:03, Sanne Grinovero wrote: > I had the same thoughts recently! > > My idea would be to have a Logger implementation which logs into an > in-memory buffer, which you can lookup somehow. For my own test needs, > even a static accessor would do. It could be a simple text > representation, or it could store a smarter event-list with some > assertion helper methods. A reset() method to be invoked at the end of > each test (or between tests as needed). > > I'd then remove Log4J from our test dependencies to primarily rely on > assertions only; or for debugging purposes to have it forwards > messages to System.out too - probably enabled by some environment > option - would be good enough. > > On 28 March 2014 11:47, Steve Ebersole wrote: >> I again have in mind adding some test assertions that a particular logging >> (WARN) message gets triggered. We have already one such test in place, >> which is one of the places where our usage of byteman comes in. >> >> Given the problems using byteman is causing in CI and the fact that our >> reliance on it is pretty light at the moment, I wanted to reach out for >> some other ideas/proposals for ways to handle this testing requirement. I >> will also reach out to David and James to see if this is something JBoss >> Logging itself could help us tackle; maybe there is some feature there >> already that would help. Any other ideas/proposals? >> _______________________________________________ >> 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 emmanuel at hibernate.org Fri Mar 28 14:44:28 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 28 Mar 2014 19:44:28 +0100 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: No strong feeling about it. It will break the OGM dialects that make use of the collection role though. So we need to anticipate. To me . looks more like the code being used and is a natural notation even beyond Java. But I get that # offers some additional info. Have you considered? org.h.SomeEntity#nv.to.hell I think that would have my preference actually. On 27 Mar 2014, at 23:54, Steve Ebersole wrote: > This is a bit of a potentially insidious one. Not the best way to start > off a discussion, I know :) > > The premise is this... Until now Hibernate has represented attribute roles > using dots. For an attribute named 'department' on the com.acme.Employee > entity, the role would be "com.acme.Employee.department". In terms of > embeddables, say Employee had an 'address' embedded with its own attributes > like 'city'. Then, the full role for 'city' would be > "com.acme.Employee.address.city". > > As you can start to see the dots here are completely indistinguishable in > terms of those which define the package/class and those which identify the > attribute "path". > > So one of the things I started playing with in 5 is to replace the > separators used in attribute paths to use '#', such that > "com.acme.Employee.address.city" would instead be > "com.acme.Employee#address#city". This makes the role fully parseable > which is actually useful in quite a few situations. And it REALLY helps in > things I have just started working on like storing metadata for composites > (embeddeds/embeddables) on the SessionFactory, which is the first step in > support for some cool new features around embeddables like discriminated > inheritance support. > > However, there is a minor drawback. Like all attributes, collections have > a role. Unfortunately the use of '.' in their role Strings leaks into the > SPI in terms of locating the CollectionPersisters. > > So the question is whether to continue with this path of replacing the use > of '.' with '#' for attribute path separators. The drawback is > unfortunate. The benefit is very nice, but I can't really say it is > required atm. > > Votes? Thoughts? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Fri Mar 28 14:45:46 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 28 Mar 2014 19:45:46 +0100 Subject: [hibernate-dev] [Search] OSGi split packages In-Reply-To: <0F6F7795-82E6-4746-B8D5-C04A050D0F4B@hibernate.org> References: <20140326125527.GF42990@hibernate.org> <31054C8E-FF12-4589-8338-ECA99EA312F0@hibernate.org> <20140327131725.GP42990@hibernate.org> <0F6F7795-82E6-4746-B8D5-C04A050D0F4B@hibernate.org> Message-ID: <8480E93F-07B8-41AC-8C8F-1EAAE6C15D5C@hibernate.org> It seems we are all ok except on the SearchFactory shuffling. Not we we agree (or disagree) on that one. On 28 Mar 2014, at 12:41, Hardy Ferentschik wrote: > Have we by now reached a consensus on wether or not to address the package split? > Anyone against generally against it? > > ?Hardy > > On 27 Jan 2014, at 14:17, Emmanuel Bernard wrote: > >> On Thu 2014-03-27 12:40, Hardy Ferentschik wrote: >>>> the tricky part is that today SearchFactoryIntegrator extends >>>> SearchFactory, but since SearchFactoryIntegrator needs to say in >>>> Engine, it can't depend on SearchFactory. What would you think of >>>> breaking this parent-child relation? >>>> From a user's perspective they wouldn't be able to narrow down their >>>> SearchFactory to an SearchFactoryIntegrator, but we could provide an >>>> unwrap backdoor. >> >> I am not following you. You no longer want a common SearchFactory >> interface usable across all event source implementations? > From steve at hibernate.org Fri Mar 28 15:54:47 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 14:54:47 -0500 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: <1F35AB5A-CE54-4C9C-A5EA-2EB525FAA74E@hibernate.org> References: <1F35AB5A-CE54-4C9C-A5EA-2EB525FAA74E@hibernate.org> Message-ID: This is not quite the same thing as what I am asking about. I'd much rather check for the execution of a specific method (CoreMessageLogger#idClassHadMappingAnnotations, e.g.) as opposed to a generic method and checking one of its String arguments. We have already had quite a bit of trouble in 5.0 tests where tests assert certain wording in exception messages as a corrolary. Relying on strings are informative text to not ever change is just not the way I'd prefer to go. On Fri, Mar 28, 2014 at 1:40 PM, Emmanuel Bernard wrote: > XWiki solved that with a JUnit rule and an in-memory log appender. I > beleive their test adds the log appender programmatically during the tests. > > > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-test/xwiki-commons-test-simple/src/main/java/org/xwiki/test/LogRule.java > > > On 28 Mar 2014, at 13:03, Sanne Grinovero wrote: > > I had the same thoughts recently! > > My idea would be to have a Logger implementation which logs into an > in-memory buffer, which you can lookup somehow. For my own test needs, > even a static accessor would do. It could be a simple text > representation, or it could store a smarter event-list with some > assertion helper methods. A reset() method to be invoked at the end of > each test (or between tests as needed). > > I'd then remove Log4J from our test dependencies to primarily rely on > assertions only; or for debugging purposes to have it forwards > messages to System.out too - probably enabled by some environment > option - would be good enough. > > On 28 March 2014 11:47, Steve Ebersole wrote: > > I again have in mind adding some test assertions that a particular logging > (WARN) message gets triggered. We have already one such test in place, > which is one of the places where our usage of byteman comes in. > > Given the problems using byteman is causing in CI and the fact that our > reliance on it is pretty light at the moment, I wanted to reach out for > some other ideas/proposals for ways to handle this testing requirement. I > will also reach out to David and James to see if this is something JBoss > Logging itself could help us tackle; maybe there is some feature there > already that would help. Any other ideas/proposals? > _______________________________________________ > 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 steve at hibernate.org Fri Mar 28 16:18:17 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Mar 2014 15:18:17 -0500 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: What we choose as a separator after the "pivot" is irrelevant to a degree, especially in terms of the compatibility concern. I think you understood that, just being clear. Meaning that calls like: sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell" ) will fail whether we use "org.h.SomeEntity#nv.to.hell" or "org.h.SomeEntity#nv#to#hell" as the role key. As for "being natural", we'll agree to disagree. But Java has no such notion as attributes so arguing about what is more natural in how Java represents attribute paths is a bit moot imo. Were these all *accessible fields*, then sure the code to access them chained would use 'dots'. But I think its pretty plain to see how in the call I listed above: sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell" ) the use of '.' locks you into never being able to programatically parse/understand that String structural, which I think is just very limiting in many places. On Fri, Mar 28, 2014 at 1:44 PM, Emmanuel Bernard wrote: > No strong feeling about it. > It will break the OGM dialects that make use of the collection role > though. So we need to anticipate. > > To me . looks more like the code being used and is a natural notation even > beyond Java. But I get that # offers some additional info. > Have you considered? > > org.h.SomeEntity#nv.to.hell > > I think that would have my preference actually. > > On 27 Mar 2014, at 23:54, Steve Ebersole wrote: > > > This is a bit of a potentially insidious one. Not the best way to start > > off a discussion, I know :) > > > > The premise is this... Until now Hibernate has represented attribute > roles > > using dots. For an attribute named 'department' on the com.acme.Employee > > entity, the role would be "com.acme.Employee.department". In terms of > > embeddables, say Employee had an 'address' embedded with its own > attributes > > like 'city'. Then, the full role for 'city' would be > > "com.acme.Employee.address.city". > > > > As you can start to see the dots here are completely indistinguishable in > > terms of those which define the package/class and those which identify > the > > attribute "path". > > > > So one of the things I started playing with in 5 is to replace the > > separators used in attribute paths to use '#', such that > > "com.acme.Employee.address.city" would instead be > > "com.acme.Employee#address#city". This makes the role fully parseable > > which is actually useful in quite a few situations. And it REALLY helps > in > > things I have just started working on like storing metadata for > composites > > (embeddeds/embeddables) on the SessionFactory, which is the first step in > > support for some cool new features around embeddables like discriminated > > inheritance support. > > > > However, there is a minor drawback. Like all attributes, collections > have > > a role. Unfortunately the use of '.' in their role Strings leaks into > the > > SPI in terms of locating the CollectionPersisters. > > > > So the question is whether to continue with this path of replacing the > use > > of '.' with '#' for attribute path separators. The drawback is > > unfortunate. The benefit is very nice, but I can't really say it is > > required atm. > > > > Votes? Thoughts? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gbadner at redhat.com Fri Mar 28 19:33:41 2014 From: gbadner at redhat.com (Gail Badner) Date: Fri, 28 Mar 2014 19:33:41 -0400 (EDT) Subject: [hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors In-Reply-To: References: <908759481.10129294.1395984902335.JavaMail.zimbra@redhat.com> <1312575400.10133909.1395985960277.JavaMail.zimbra@redhat.com> Message-ID: <1229131229.10800702.1396049621295.JavaMail.zimbra@redhat.com> Just for the record, upgrading to Java 1.7.0_51 fixed the build for me. ----- Original Message ----- > From: "Steve Ebersole" > To: "Gail Badner" > Cc: "Hibernate" > Sent: Friday, March 28, 2014 4:22:35 AM > Subject: Re: [hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors > > Nope, but this would local to your system. It works for me and it is > working in CI > > > On Fri, Mar 28, 2014 at 12:52 AM, Gail Badner wrote: > > > After pulling, I am getting a failure executing > > :hibernate-core:runAnnotationProcessors. > > > > I tried building with --debug and it looks like the > > hibernate-core/target/generated-src/apt/main is deleted without being > > re-generated. When hibernate-core is compiled, there are failures because > > package org.hibernate.hql.internal.antlr does not exist. > > > > Anyone have ideas why this is happening? > > > > Thanks, > > Gail > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From steve at hibernate.org Sat Mar 29 12:40:02 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 29 Mar 2014 11:40:02 -0500 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: To wrap this up.. The most important part for me is being able to identify the point between the "attribute base" and the "attribute path". If we just use a separate delimiter there, that's enough for me. Since one of us has a preference for using dots within the "attribute path" part (and its irrelevant to me), I'll go with that. So: org.h.SomeEntity#nv.to.hell On Fri, Mar 28, 2014 at 3:18 PM, Steve Ebersole wrote: > What we choose as a separator after the "pivot" is irrelevant to a degree, > especially in terms of the compatibility concern. I think you understood > that, just being clear. Meaning that calls like: > > sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell" > ) > > will fail whether we use "org.h.SomeEntity#nv.to.hell" or "org.h.SomeEntity#nv#to#hell" > as the role key. > > As for "being natural", we'll agree to disagree. But Java has no such > notion as attributes so arguing about what is more natural in how Java > represents attribute paths is a bit moot imo. Were these all *accessible > fields*, then sure the code to access them chained would use 'dots'. But I > think its pretty plain to see how in the call I listed above: > > sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell" > ) > > the use of '.' locks you into never being able to programatically > parse/understand that String structural, which I think is just very > limiting in many places. > > > > On Fri, Mar 28, 2014 at 1:44 PM, Emmanuel Bernard wrote: > >> No strong feeling about it. >> It will break the OGM dialects that make use of the collection role >> though. So we need to anticipate. >> >> To me . looks more like the code being used and is a natural notation >> even beyond Java. But I get that # offers some additional info. >> Have you considered? >> >> org.h.SomeEntity#nv.to.hell >> >> I think that would have my preference actually. >> >> On 27 Mar 2014, at 23:54, Steve Ebersole wrote: >> >> > This is a bit of a potentially insidious one. Not the best way to start >> > off a discussion, I know :) >> > >> > The premise is this... Until now Hibernate has represented attribute >> roles >> > using dots. For an attribute named 'department' on the >> com.acme.Employee >> > entity, the role would be "com.acme.Employee.department". In terms of >> > embeddables, say Employee had an 'address' embedded with its own >> attributes >> > like 'city'. Then, the full role for 'city' would be >> > "com.acme.Employee.address.city". >> > >> > As you can start to see the dots here are completely indistinguishable >> in >> > terms of those which define the package/class and those which identify >> the >> > attribute "path". >> > >> > So one of the things I started playing with in 5 is to replace the >> > separators used in attribute paths to use '#', such that >> > "com.acme.Employee.address.city" would instead be >> > "com.acme.Employee#address#city". This makes the role fully parseable >> > which is actually useful in quite a few situations. And it REALLY >> helps in >> > things I have just started working on like storing metadata for >> composites >> > (embeddeds/embeddables) on the SessionFactory, which is the first step >> in >> > support for some cool new features around embeddables like discriminated >> > inheritance support. >> > >> > However, there is a minor drawback. Like all attributes, collections >> have >> > a role. Unfortunately the use of '.' in their role Strings leaks into >> the >> > SPI in terms of locating the CollectionPersisters. >> > >> > So the question is whether to continue with this path of replacing the >> use >> > of '.' with '#' for attribute path separators. The drawback is >> > unfortunate. The benefit is very nice, but I can't really say it is >> > required atm. >> > >> > Votes? Thoughts? >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From steve at hibernate.org Sat Mar 29 12:59:47 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 29 Mar 2014 11:59:47 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: Since there seems to be no unanimous consensus, the majority consensus seems to be to for that (1) approach. So that's going to be my working principle here for now. Another thought... Again to me this all comes down to 1 concept in JPA being used to represent 3 different things. That's never a good situation. So maybe internally we start representing all 3 distinctly. As we model and understand things separately it makes it easier to handle each separately. For example, we might have: 1) A strategy for recognizing the persistent attributes for a class 2) A (swappable, maybe) strategy for collecting the mapping annotations related to a persistent attribute 3) A strategy for accessing the attribute at runtime (our PropertyAccessor stuff). (2) would be the thing that would allow for what Sanne is asking about. By default we'd not support that, but through a switch or pluggable strategy would could. Agains, there are 3 parts to this discussion. Previously we modeled 1! I have just changed this recently to model 2. Maybe we actually model all 3? On Thu, Mar 27, 2014 at 2:01 PM, Hardy Ferentschik wrote: > > On 27 Jan 2014, at 19:36, Steve Ebersole wrote: > > > Here is what I am trying to decide between in terms of support for this. > Mainly this is a usability matter for me. Part of usability is how easily > we can explain this so users can understand and use it. To me there are 2 > paths to high usability here... > > > > > > == Consistency > > > > The first path would be to be consistent in what "access type" means and > its implications. For example, to me that would mean at the beginning of > this topical guide I can make the following statement truthfully, then to > me we have consistency: > > > > > > A persistent attribute is defined as either FIELD or PROPERTY access (in > strict JPA sense). FIELD access means that: > > 1) A persistent attribute is identified by its Class field > > 2) The mapping annotations for the persistent attribute are located on > the Class field > > 3) At runtime we access the persistent attribute's value directly via > the field. > > > > PROPERTY access means: > > 1) A persistent attribute is identified by its JavaBeans-style getter > and setter on a Class > > 2) The mapping annotations for the persistent attribute are located on > the Class getter method > > 3) At runtime we access the persistent attribute's value via the > getter/setter methods. > > > > > > From there its just a matter of rules for "which" wins at the various > levels (hierarchy, class, attribute). > > My vote goes to consistency. > > > > == ItJustWorks > > > > This is more the proposal of Sanne iiuc. Here, "where to look for > mapping annotations" is irrelevant; the idea being that we'd look both on > the field and the getter and "merge" the metadata. Another implication > here is that @Access explicitly identifies how they are accessed at runtime > (and I'd assume this in turn drives the recognition of what are the > persistent attributes). > > > > There is definitely a beauty here in that the rules are again pretty > simple to explain and understand. The thing that worries me is the part > about "merging" the metadata. Sanne gave some simple examples of where > this would possibly be difficult. But there are others, some even more > difficult. One that immediately jumps to my mind is "plural" annotations; > for example: > > > > @ManyToOne > > @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) > > private Person person; > > > > @ManyToOne > > @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} ) > > public getPerson() { return person; } > > > > Is this 4 join-columns? 2? Error? > > > > I think at the very least we should be enforcing that the annotations > appear consistently (either all on field or all on getter) for a given > attribute *if* we were to go this route. > > Right, that would be the minimum requirement. From hardy at hibernate.org Sat Mar 29 15:06:42 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Sat, 29 Mar 2014 20:06:42 +0100 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: On 29 Jan 2014, at 17:59, Steve Ebersole wrote: > Again to me this all comes down to 1 concept in JPA being used to represent 3 different things. That's never a good situation. So maybe internally we start representing all 3 distinctly. That?s sounds like a good idea which would give us most flexibility. It might create a fair bit of more work initially though. ?Hardy From hardy at hibernate.org Sat Mar 29 15:24:00 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Sat, 29 Mar 2014 20:24:00 +0100 Subject: [hibernate-dev] Tests asserting warnings get logged In-Reply-To: References: <00C0D461-6F6F-472B-826F-F09E6BFF51B7@hibernate.org> Message-ID: On 28 Jan 2014, at 13:55, Steve Ebersole wrote: > > On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote: > > > > > > On 28 Jan 2014, at 12:47, Steve Ebersole wrote: > > > > > Given the problems using byteman is causing in CI > > > > What problem is that? > > Port contention of some sort Is this the only problem you are having with the use of Byteman? I for my part find the current solution sufficient for the few cases where we want to assert that a given message gets logged. Could we not try resolving the CI issue? ?Hardy From sanne at hibernate.org Sat Mar 29 15:25:40 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 29 Mar 2014 19:25:40 +0000 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: On 29 March 2014 16:40, Steve Ebersole wrote: > To wrap this up.. > > The most important part for me is being able to identify the point between > the "attribute base" and the "attribute path". If we just use a separate > delimiter there, that's enough for me. Since one of us has a preference > for using dots within the "attribute path" part (and its irrelevant to me), > I'll go with that. So: > > org.h.SomeEntity#nv.to.hell Nice, I like this most too as it's consistent with how we represent attributes for queries in Search. Sanne From steve at hibernate.org Sun Mar 30 10:51:00 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 30 Mar 2014 09:51:00 -0500 Subject: [hibernate-dev] Another @Access quandry In-Reply-To: References: <20140326130216.GG42990@hibernate.org> <20140326162159.GK42990@hibernate.org> <6A185A2E-99FA-4BD5-8F35-AAF9CDA6920A@hibernate.org> <71CD7D15-68D1-4C50-8998-B861FFB1F885@hibernate.org> Message-ID: I have pushed the latest topical guide: https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc Thoughts? Comments? The "Attribute-level" section is still undone, but I think the rest of the text lays out the expectations in that case (especially the "Extensions" sections) ... On Sat, Mar 29, 2014 at 2:06 PM, Hardy Ferentschik wrote: > > On 29 Jan 2014, at 17:59, Steve Ebersole wrote: > > > Again to me this all comes down to 1 concept in JPA being used to > represent 3 different things. That's never a good situation. So maybe > internally we start representing all 3 distinctly. > > That's sounds like a good idea which would give us most flexibility. It > might create a fair bit of more work initially though. > > --Hardy > > > From gunnar at hibernate.org Mon Mar 31 05:02:03 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 11:02:03 +0200 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: 2014-03-29 17:40 GMT+01:00 Steve Ebersole : > To wrap this up.. > > The most important part for me is being able to identify the point between > the "attribute base" and the "attribute path". If we just use a separate > delimiter there, that's enough for me. Since one of us has a preference > for using dots within the "attribute path" part (and its irrelevant to me), > I'll go with that. So: > > org.h.SomeEntity#nv.to.hell > +1 for that. You might also consider to use "::" as the delimiter between base and path: org.h.SomeEntity::nv.to.hell "::" is the syntax for method references in Java 8 and it may possibly be used for field references as well in a future Java version. So in some way it may be nice to resemble that. --Gunnar > > > > On Fri, Mar 28, 2014 at 3:18 PM, Steve Ebersole > wrote: > > > What we choose as a separator after the "pivot" is irrelevant to a > degree, > > especially in terms of the compatibility concern. I think you understood > > that, just being clear. Meaning that calls like: > > > > sessionFactoryImplementor.getCollectionPersister( > "org.h.SomeEntity.nv.to.hell" > > ) > > > > will fail whether we use "org.h.SomeEntity#nv.to.hell" or > "org.h.SomeEntity#nv#to#hell" > > as the role key. > > > > As for "being natural", we'll agree to disagree. But Java has no such > > notion as attributes so arguing about what is more natural in how Java > > represents attribute paths is a bit moot imo. Were these all *accessible > > fields*, then sure the code to access them chained would use 'dots'. > But I > > think its pretty plain to see how in the call I listed above: > > > > sessionFactoryImplementor.getCollectionPersister( > "org.h.SomeEntity.nv.to.hell" > > ) > > > > the use of '.' locks you into never being able to programatically > > parse/understand that String structural, which I think is just very > > limiting in many places. > > > > > > > > On Fri, Mar 28, 2014 at 1:44 PM, Emmanuel Bernard < > emmanuel at hibernate.org>wrote: > > > >> No strong feeling about it. > >> It will break the OGM dialects that make use of the collection role > >> though. So we need to anticipate. > >> > >> To me . looks more like the code being used and is a natural notation > >> even beyond Java. But I get that # offers some additional info. > >> Have you considered? > >> > >> org.h.SomeEntity#nv.to.hell > >> > >> I think that would have my preference actually. > >> > >> On 27 Mar 2014, at 23:54, Steve Ebersole wrote: > >> > >> > This is a bit of a potentially insidious one. Not the best way to > start > >> > off a discussion, I know :) > >> > > >> > The premise is this... Until now Hibernate has represented attribute > >> roles > >> > using dots. For an attribute named 'department' on the > >> com.acme.Employee > >> > entity, the role would be "com.acme.Employee.department". In terms of > >> > embeddables, say Employee had an 'address' embedded with its own > >> attributes > >> > like 'city'. Then, the full role for 'city' would be > >> > "com.acme.Employee.address.city". > >> > > >> > As you can start to see the dots here are completely indistinguishable > >> in > >> > terms of those which define the package/class and those which identify > >> the > >> > attribute "path". > >> > > >> > So one of the things I started playing with in 5 is to replace the > >> > separators used in attribute paths to use '#', such that > >> > "com.acme.Employee.address.city" would instead be > >> > "com.acme.Employee#address#city". This makes the role fully parseable > >> > which is actually useful in quite a few situations. And it REALLY > >> helps in > >> > things I have just started working on like storing metadata for > >> composites > >> > (embeddeds/embeddables) on the SessionFactory, which is the first step > >> in > >> > support for some cool new features around embeddables like > discriminated > >> > inheritance support. > >> > > >> > However, there is a minor drawback. Like all attributes, collections > >> have > >> > a role. Unfortunately the use of '.' in their role Strings leaks into > >> the > >> > SPI in terms of locating the CollectionPersisters. > >> > > >> > So the question is whether to continue with this path of replacing the > >> use > >> > of '.' with '#' for attribute path separators. The drawback is > >> > unfortunate. The benefit is very nice, but I can't really say it is > >> > required atm. > >> > > >> > Votes? Thoughts? > >> > _______________________________________________ > >> > 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 Mon Mar 31 05:40:24 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 11:40:24 +0200 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: +1 One potential issue coming to mind is that this will require Hibernate OGM users to work with Java 7 as well (at least when using queries via Hibernate Search). When discussing the issue (for OGM) last time, we decided to stick to Java 6 to ease OGM experiments of existing Hibernate ORM users. Personally I don't think it's a problem, (I had wished to move OGM to Java 7 before), just pointing out the fact so that there are no surprises. So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 features in OGM as well. --Gunnar 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : > +100 > > On 20 Jan 2014, at 16:21, Sanne Grinovero wrote: > > > The next minor release of Apache Lucene v. 4.8 will require Java7. > > > > The Lucene team has highlighted many good reasons for that, including > > some excellent improvements in sorting performance and reliability of > > IO operations: nice things we'd like to take advantage of. > > > > Objections against baseling Hibernate Search 5 to *require* Java7 too? > > We hardly have a choice, so objections better be good ;-) > > > > -- Sanne > > _______________________________________________ > > 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 Mon Mar 31 06:07:54 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 12:07:54 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: <20140320220523.GC10878@hibernate.org> References: <20140320220523.GC10878@hibernate.org> Message-ID: 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > I took some more time to think about our conversation from 2 IRC meeting > ago > about offering the ability to carry session bound state not related to > ORM per se. > Below is a sum and a potential solution. > If you are short on time, read Goals, then the SessionSessionEventListener > approach and ignore the rest. > > ## Goals > > The goal is to be able to carry session bound state for non-ORM projects > like search and OGM. > We want to avoid ThreadLocal use, in particular when it cannot be > protected by a try / catch for proper resource cleaning. > We want to avoid a structure that would be shared across threads > concurrently > i.e. using ConcurrentHashMap with a Weak reference to the session. > It needs to be informed of a call to session.clear() > It needs to be informed of a call to session.close() > The state needs to be accessed from event listener implementations and > custom > persister / loader implementations i.e. SessionImplementor and maybe > EventSource? > > ## Approaches > > I'll discuss the approaches we explored in the meeting and then offer an > alternative one that I think is pretty interesting and fit better with > the current Session model. > > ### Map > > This is essentially sticking a map on SessionImpl and use it to carry > state. > The following is a pseudo implementation > > > /** > * interface implemented by SessionImpl and the like > */ > interface SessionCompanion { > Object getCompanion(String key); > void addCompanion(String key, Object companion); > void removeCompanion(String key); > } > > > /** > * adds a map to the SessionImpl > */ > SessionImpl { > private Map companions; > public Object getCompanion(String key) { return > companions.get(key); } > public void addCompanion(String key, Object value) { > companions.add(key, companion); } > public void removeCompanion(String key) { companions.remove(key) } > } > > The persister or event listener would call SessionCompation.*Companion > method > to put and retrieve its state. > > There is no clear / close event listener loop and it would need to be > added. > > ### Delegator > > Gunnar and teve discussed an approach where the delegator would be passed > to > the underlying session and be accessible via an `unwrap` method. > I have not followed the details but this approach has one major flaw: the > delegator (OgmSession, FullTextSession etc) is not always created and thus > would not be necessarily available. > A somewhat similar idea involving passing the session owner has the same > drawback. And another one described by Gunnar in > https://hibernate.atlassian.net/browse/OGM-469 > > ### The type-safe map approach > > This approach is vaguely similar to the Map approach except that the > payload is > represented and looked up by Class. This has the benefit of not having > namespace problems and is generally less String-y. > > > /** > * interface implemented by SessionImpl and the like > */ > interface SessionCompanion { > T getCompanion(Class type); > void addCompanion(Object companion); > void removeCompanion(Class type) > > } > > > SessionImpl { > //could also use an array or an ArrayList > private Map, Object> companions; > public T getCompanion(Class type) { return (T) > companions.get(type); } > public void addCompanion(Object companion) { > companions.add(companion.getClass(), type); } > public void removeCompanion(Class type) { > companions.remove(type); } > } > > Like in the Map approach, the persister or custom event listener would > interact > with SessionCompanion. > There are open issues like what should be done when two objects of the same > type are added to the same session. > Likewise the clear / close hook issues need to be addressed. > > ### the SessionEventListener approach > > I did not know but there is a concept of `SessionEventListener` which can > be > added to a `SessionImplementor`. It has hooks that are addressing most of > the > goals. > > > //interface already exists > interface SessionImplementor { > public SessionEventListenerManager getEventListenerManager(); > } > > //interface already exists > public interface SessionEventListenerManager extends > SessionEventListener { > // add this method to be able to retrieve a specific listener > holding some state for a 3rd party project > List getSessionEventListeners(); > } > > OGM or Search would implement a `SessionEventListener` and attach an > instance to a session via `Session.addEventListeners()`. > It would require to add a method to retrieve the list of > `SessionEventListener`s attached to a `SessionEventListenerManager`. > > List listeners = > sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); > OgmSessionEventListener ogmListener = > findOrAddOgmListener(sessionImplementor, listeners); > ogmListener.someStuff(); > > ## What about clear and close? > > We have a few ways to react to these. > SessionEventListener is already called back when a flush begins / ends as > well as when Session closes. > We need to either: > > - add a clear begins / ends callback > - have the third party project add a ClearEventListener which would access > the SessionEventListeners and do some magic. > > The first approach has my preference and would do: > > > public interface SessionEventListener { > [...] > void clearStart(); > void clearEnd(); > } > > What do you guys think? The SessionEventListener approach feels more > natural. > Tbh. I feel maintaining the state with a listener is a bit hacky. How would we find "our" listener, I guess it would involve some ugly instanceof check? The map based approaches seem preferable to me (I dislike the "companion" naming scheme though). The type-safe map approach is nice, as you say it may cause type collisions though and lead to a proliferation of key types. How about a combined approach which provides one such typesafe container per "client": public interface SessionAttributes { T get(Class type); T put(Class type, T value); T remove(Class type); } And public interface SessionImplementor { ... SessionAttributes getAttributes(String integratorId); } And in OGM: public static final String OGM_COMMON_ATTRIBUTES = "org.hibernate.ogm.attributes.common"; ... FooBar fb = session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); This avoids collisions of attributes of the same type between different clients such as OGM and Search (there could even be several attribute containers used by one client). The SessionAttributes could be instantiated lazily upon the first getAttributes() call, avoiding any overhead if the functionality is not used. The clean-up part (if it is required?) could then be done by an accompanying SessionEventListener. --Gunnar > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Mar 31 06:08:12 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 31 Mar 2014 11:08:12 +0100 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: Since Hibernate OGM is now an implementation of JPA 2.1, doesn't it already require Java 7? You could also decide to use Java7 for the build but not necessarily make use of Java7 features, as Search is an optional dependency. (but I also don't see a problem on moving). I would like to encourage OGM to switch to Search 5 soon though: the HQL parser is aligning already, and some features we're working on in Search are meant to improve the user experience for OGM users specifically (HSEARCH-1119), not least it's the version meant for Infinispan 7, which OGM will need to support a GridDialect over HotRod. And solid performance improvements as usual ;-) -- Sanne On 31 March 2014 10:40, Gunnar Morling wrote: > +1 > > One potential issue coming to mind is that this will require Hibernate OGM > users to work with Java 7 as well (at least when using queries via Hibernate > Search). > > When discussing the issue (for OGM) last time, we decided to stick to Java 6 > to ease OGM experiments of existing Hibernate ORM users. Personally I don't > think it's a problem, (I had wished to move OGM to Java 7 before), just > pointing out the fact so that there are no surprises. > > So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 features > in OGM as well. > > --Gunnar > > > > > 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : > >> +100 >> >> On 20 Jan 2014, at 16:21, Sanne Grinovero wrote: >> >> > The next minor release of Apache Lucene v. 4.8 will require Java7. >> > >> > The Lucene team has highlighted many good reasons for that, including >> > some excellent improvements in sorting performance and reliability of >> > IO operations: nice things we'd like to take advantage of. >> > >> > Objections against baseling Hibernate Search 5 to *require* Java7 too? >> > We hardly have a choice, so objections better be good ;-) >> > >> > -- Sanne >> > _______________________________________________ >> > 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 Mon Mar 31 06:16:29 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 12:16:29 +0200 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: 2014-03-31 12:08 GMT+02:00 Sanne Grinovero : > Since Hibernate OGM is now an implementation of JPA 2.1, doesn't it > already require Java 7? > Good point; Not sure whether JPA 2.1 per-se really requires Java 7, but I understand as an implementation we'd be "allowed" to require Java 7 as per the spec guidelines. So far, 6 seemed sufficient for our purposes. You could also decide to use Java7 for the build but not necessarily > make use of Java7 features, as Search is an optional dependency. (but > I also don't see a problem on moving). > Yes, I thought about this as well, but it makes a difficult story to explain (depending on whether you use JP-QL or not, and depending on the backend you use, you may be use Java 6 or 7). I'd rather move to 7 altogether then and keep things a bit simpler. > > I would like to encourage OGM to switch to Search 5 soon though: the > HQL parser is aligning already, and some features we're working on in > Search are meant to improve the user experience for OGM users > specifically (HSEARCH-1119), not least it's the version meant for > Infinispan 7, which OGM will need to support a GridDialect over > HotRod. And solid performance improvements as usual ;-) > +1 :-) > > -- Sanne > > On 31 March 2014 10:40, Gunnar Morling wrote: > > +1 > > > > One potential issue coming to mind is that this will require Hibernate > OGM > > users to work with Java 7 as well (at least when using queries via > Hibernate > > Search). > > > > When discussing the issue (for OGM) last time, we decided to stick to > Java 6 > > to ease OGM experiments of existing Hibernate ORM users. Personally I > don't > > think it's a problem, (I had wished to move OGM to Java 7 before), just > > pointing out the fact so that there are no surprises. > > > > So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 > features > > in OGM as well. > > > > --Gunnar > > > > > > > > > > 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : > > > >> +100 > >> > >> On 20 Jan 2014, at 16:21, Sanne Grinovero wrote: > >> > >> > The next minor release of Apache Lucene v. 4.8 will require Java7. > >> > > >> > The Lucene team has highlighted many good reasons for that, including > >> > some excellent improvements in sorting performance and reliability of > >> > IO operations: nice things we'd like to take advantage of. > >> > > >> > Objections against baseling Hibernate Search 5 to *require* Java7 too? > >> > We hardly have a choice, so objections better be good ;-) > >> > > >> > -- Sanne > >> > _______________________________________________ > >> > 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 emmanuel at hibernate.org Mon Mar 31 08:31:25 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 31 Mar 2014 14:31:25 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: References: <20140320220523.GC10878@hibernate.org> Message-ID: <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> The thing is, the map approach had a big -1 from Steve hanging on its head :) > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : >> I took some more time to think about our conversation from 2 IRC meeting ago >> about offering the ability to carry session bound state not related to >> ORM per se. >> Below is a sum and a potential solution. >> If you are short on time, read Goals, then the SessionSessionEventListener >> approach and ignore the rest. >> >> ## Goals >> >> The goal is to be able to carry session bound state for non-ORM projects >> like search and OGM. >> We want to avoid ThreadLocal use, in particular when it cannot be >> protected by a try / catch for proper resource cleaning. >> We want to avoid a structure that would be shared across threads concurrently >> i.e. using ConcurrentHashMap with a Weak reference to the session. >> It needs to be informed of a call to session.clear() >> It needs to be informed of a call to session.close() >> The state needs to be accessed from event listener implementations and custom >> persister / loader implementations i.e. SessionImplementor and maybe >> EventSource? >> >> ## Approaches >> >> I'll discuss the approaches we explored in the meeting and then offer an >> alternative one that I think is pretty interesting and fit better with >> the current Session model. >> >> ### Map >> >> This is essentially sticking a map on SessionImpl and use it to carry >> state. >> The following is a pseudo implementation >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> Object getCompanion(String key); >> void addCompanion(String key, Object companion); >> void removeCompanion(String key); >> } >> >> >> /** >> * adds a map to the SessionImpl >> */ >> SessionImpl { >> private Map companions; >> public Object getCompanion(String key) { return companions.get(key); } >> public void addCompanion(String key, Object value) { companions.add(key, companion); } >> public void removeCompanion(String key) { companions.remove(key) } >> } >> >> The persister or event listener would call SessionCompation.*Companion method >> to put and retrieve its state. >> >> There is no clear / close event listener loop and it would need to be added. >> >> ### Delegator >> >> Gunnar and teve discussed an approach where the delegator would be passed to >> the underlying session and be accessible via an `unwrap` method. >> I have not followed the details but this approach has one major flaw: the >> delegator (OgmSession, FullTextSession etc) is not always created and thus >> would not be necessarily available. >> A somewhat similar idea involving passing the session owner has the same >> drawback. And another one described by Gunnar in >> https://hibernate.atlassian.net/browse/OGM-469 >> >> ### The type-safe map approach >> >> This approach is vaguely similar to the Map approach except that the payload is >> represented and looked up by Class. This has the benefit of not having >> namespace problems and is generally less String-y. >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> T getCompanion(Class type); >> void addCompanion(Object companion); >> void removeCompanion(Class type) >> >> } >> >> >> SessionImpl { >> //could also use an array or an ArrayList >> private Map, Object> companions; >> public T getCompanion(Class type) { return (T) companions.get(type); } >> public void addCompanion(Object companion) { companions.add(companion.getClass(), type); } >> public void removeCompanion(Class type) { companions.remove(type); } >> } >> >> Like in the Map approach, the persister or custom event listener would interact >> with SessionCompanion. >> There are open issues like what should be done when two objects of the same >> type are added to the same session. >> Likewise the clear / close hook issues need to be addressed. >> >> ### the SessionEventListener approach >> >> I did not know but there is a concept of `SessionEventListener` which can be >> added to a `SessionImplementor`. It has hooks that are addressing most of the >> goals. >> >> >> //interface already exists >> interface SessionImplementor { >> public SessionEventListenerManager getEventListenerManager(); >> } >> >> //interface already exists >> public interface SessionEventListenerManager extends SessionEventListener { >> // add this method to be able to retrieve a specific listener holding some state for a 3rd party project >> List getSessionEventListeners(); >> } >> >> OGM or Search would implement a `SessionEventListener` and attach an instance to a session via `Session.addEventListeners()`. >> It would require to add a method to retrieve the list of `SessionEventListener`s attached to a `SessionEventListenerManager`. >> >> List listeners = sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); >> OgmSessionEventListener ogmListener = findOrAddOgmListener(sessionImplementor, listeners); >> ogmListener.someStuff(); >> >> ## What about clear and close? >> >> We have a few ways to react to these. >> SessionEventListener is already called back when a flush begins / ends as well as when Session closes. >> We need to either: >> >> - add a clear begins / ends callback >> - have the third party project add a ClearEventListener which would access the SessionEventListeners and do some magic. >> >> The first approach has my preference and would do: >> >> >> public interface SessionEventListener { >> [...] >> void clearStart(); >> void clearEnd(); >> } >> >> What do you guys think? The SessionEventListener approach feels more natural. > > Tbh. I feel maintaining the state with a listener is a bit hacky. How would we find "our" listener, I guess it would involve some ugly instanceof check? > > The map based approaches seem preferable to me (I dislike the "companion" naming scheme though). The type-safe map approach is nice, as you say it may cause type collisions though and lead to a proliferation of key types. How about a combined approach which provides one such typesafe container per "client": > > public interface SessionAttributes { > > T get(Class type); > T put(Class type, T value); > T remove(Class type); > } > > And > > public interface SessionImplementor { > ... > SessionAttributes getAttributes(String integratorId); > } > > And in OGM: > > public static final String OGM_COMMON_ATTRIBUTES = "org.hibernate.ogm.attributes.common"; > ... > FooBar fb = session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > This avoids collisions of attributes of the same type between different clients such as OGM and Search (there could even be several attribute containers used by one client). The SessionAttributes could be instantiated lazily upon the first getAttributes() call, avoiding any overhead if the functionality is not used. > > The clean-up part (if it is required?) could then be done by an accompanying SessionEventListener. > > --Gunnar > >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Mon Mar 31 08:35:32 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 31 Mar 2014 14:35:32 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: References: <20140320220523.GC10878@hibernate.org> Message-ID: <46B9879B-AD1F-4FEB-9E6A-BA2C4FDAFB07@hibernate.org> Btw to answer your concern about the event listeners and the use of instance of, we could imagine an API like getListenerOfType(Class) on the SessionEventListenerManager. Because one key thing that this approach solves and that the map approach does not is the actual event listener callback capability on close, flush, etc > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : >> I took some more time to think about our conversation from 2 IRC meeting ago >> about offering the ability to carry session bound state not related to >> ORM per se. >> Below is a sum and a potential solution. >> If you are short on time, read Goals, then the SessionSessionEventListener >> approach and ignore the rest. >> >> ## Goals >> >> The goal is to be able to carry session bound state for non-ORM projects >> like search and OGM. >> We want to avoid ThreadLocal use, in particular when it cannot be >> protected by a try / catch for proper resource cleaning. >> We want to avoid a structure that would be shared across threads concurrently >> i.e. using ConcurrentHashMap with a Weak reference to the session. >> It needs to be informed of a call to session.clear() >> It needs to be informed of a call to session.close() >> The state needs to be accessed from event listener implementations and custom >> persister / loader implementations i.e. SessionImplementor and maybe >> EventSource? >> >> ## Approaches >> >> I'll discuss the approaches we explored in the meeting and then offer an >> alternative one that I think is pretty interesting and fit better with >> the current Session model. >> >> ### Map >> >> This is essentially sticking a map on SessionImpl and use it to carry >> state. >> The following is a pseudo implementation >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> Object getCompanion(String key); >> void addCompanion(String key, Object companion); >> void removeCompanion(String key); >> } >> >> >> /** >> * adds a map to the SessionImpl >> */ >> SessionImpl { >> private Map companions; >> public Object getCompanion(String key) { return companions.get(key); } >> public void addCompanion(String key, Object value) { companions.add(key, companion); } >> public void removeCompanion(String key) { companions.remove(key) } >> } >> >> The persister or event listener would call SessionCompation.*Companion method >> to put and retrieve its state. >> >> There is no clear / close event listener loop and it would need to be added. >> >> ### Delegator >> >> Gunnar and teve discussed an approach where the delegator would be passed to >> the underlying session and be accessible via an `unwrap` method. >> I have not followed the details but this approach has one major flaw: the >> delegator (OgmSession, FullTextSession etc) is not always created and thus >> would not be necessarily available. >> A somewhat similar idea involving passing the session owner has the same >> drawback. And another one described by Gunnar in >> https://hibernate.atlassian.net/browse/OGM-469 >> >> ### The type-safe map approach >> >> This approach is vaguely similar to the Map approach except that the payload is >> represented and looked up by Class. This has the benefit of not having >> namespace problems and is generally less String-y. >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> T getCompanion(Class type); >> void addCompanion(Object companion); >> void removeCompanion(Class type) >> >> } >> >> >> SessionImpl { >> //could also use an array or an ArrayList >> private Map, Object> companions; >> public T getCompanion(Class type) { return (T) companions.get(type); } >> public void addCompanion(Object companion) { companions.add(companion.getClass(), type); } >> public void removeCompanion(Class type) { companions.remove(type); } >> } >> >> Like in the Map approach, the persister or custom event listener would interact >> with SessionCompanion. >> There are open issues like what should be done when two objects of the same >> type are added to the same session. >> Likewise the clear / close hook issues need to be addressed. >> >> ### the SessionEventListener approach >> >> I did not know but there is a concept of `SessionEventListener` which can be >> added to a `SessionImplementor`. It has hooks that are addressing most of the >> goals. >> >> >> //interface already exists >> interface SessionImplementor { >> public SessionEventListenerManager getEventListenerManager(); >> } >> >> //interface already exists >> public interface SessionEventListenerManager extends SessionEventListener { >> // add this method to be able to retrieve a specific listener holding some state for a 3rd party project >> List getSessionEventListeners(); >> } >> >> OGM or Search would implement a `SessionEventListener` and attach an instance to a session via `Session.addEventListeners()`. >> It would require to add a method to retrieve the list of `SessionEventListener`s attached to a `SessionEventListenerManager`. >> >> List listeners = sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); >> OgmSessionEventListener ogmListener = findOrAddOgmListener(sessionImplementor, listeners); >> ogmListener.someStuff(); >> >> ## What about clear and close? >> >> We have a few ways to react to these. >> SessionEventListener is already called back when a flush begins / ends as well as when Session closes. >> We need to either: >> >> - add a clear begins / ends callback >> - have the third party project add a ClearEventListener which would access the SessionEventListeners and do some magic. >> >> The first approach has my preference and would do: >> >> >> public interface SessionEventListener { >> [...] >> void clearStart(); >> void clearEnd(); >> } >> >> What do you guys think? The SessionEventListener approach feels more natural. > > Tbh. I feel maintaining the state with a listener is a bit hacky. How would we find "our" listener, I guess it would involve some ugly instanceof check? > > The map based approaches seem preferable to me (I dislike the "companion" naming scheme though). The type-safe map approach is nice, as you say it may cause type collisions though and lead to a proliferation of key types. How about a combined approach which provides one such typesafe container per "client": > > public interface SessionAttributes { > > T get(Class type); > T put(Class type, T value); > T remove(Class type); > } > > And > > public interface SessionImplementor { > ... > SessionAttributes getAttributes(String integratorId); > } > > And in OGM: > > public static final String OGM_COMMON_ATTRIBUTES = "org.hibernate.ogm.attributes.common"; > ... > FooBar fb = session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > This avoids collisions of attributes of the same type between different clients such as OGM and Search (there could even be several attribute containers used by one client). The SessionAttributes could be instantiated lazily upon the first getAttributes() call, avoiding any overhead if the functionality is not used. > > The clean-up part (if it is required?) could then be done by an accompanying SessionEventListener. > > --Gunnar > >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Mon Mar 31 08:45:21 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 14:45:21 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> References: <20140320220523.GC10878@hibernate.org> <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> Message-ID: 2014-03-31 14:31 GMT+02:00 Emmanuel Bernard : > The thing is, the map approach had a big -1 from Steve hanging on its head > :) > Yes, I know :) But when the map initialization is done lazily as suggested, would there really be any problem with that? SessionImpl would have a null reference to the map in the non-OGM case. > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > >> I took some more time to think about our conversation from 2 IRC meeting >> ago >> about offering the ability to carry session bound state not related to >> ORM per se. >> Below is a sum and a potential solution. >> If you are short on time, read Goals, then the SessionSessionEventListener >> approach and ignore the rest. >> >> ## Goals >> >> The goal is to be able to carry session bound state for non-ORM projects >> like search and OGM. >> We want to avoid ThreadLocal use, in particular when it cannot be >> protected by a try / catch for proper resource cleaning. >> We want to avoid a structure that would be shared across threads >> concurrently >> i.e. using ConcurrentHashMap with a Weak reference to the session. >> It needs to be informed of a call to session.clear() >> It needs to be informed of a call to session.close() >> The state needs to be accessed from event listener implementations and >> custom >> persister / loader implementations i.e. SessionImplementor and maybe >> EventSource? >> >> ## Approaches >> >> I'll discuss the approaches we explored in the meeting and then offer an >> alternative one that I think is pretty interesting and fit better with >> the current Session model. >> >> ### Map >> >> This is essentially sticking a map on SessionImpl and use it to carry >> state. >> The following is a pseudo implementation >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> Object getCompanion(String key); >> void addCompanion(String key, Object companion); >> void removeCompanion(String key); >> } >> >> >> /** >> * adds a map to the SessionImpl >> */ >> SessionImpl { >> private Map companions; >> public Object getCompanion(String key) { return >> companions.get(key); } >> public void addCompanion(String key, Object value) { >> companions.add(key, companion); } >> public void removeCompanion(String key) { companions.remove(key) } >> } >> >> The persister or event listener would call SessionCompation.*Companion >> method >> to put and retrieve its state. >> >> There is no clear / close event listener loop and it would need to be >> added. >> >> ### Delegator >> >> Gunnar and teve discussed an approach where the delegator would be passed >> to >> the underlying session and be accessible via an `unwrap` method. >> I have not followed the details but this approach has one major flaw: the >> delegator (OgmSession, FullTextSession etc) is not always created and thus >> would not be necessarily available. >> A somewhat similar idea involving passing the session owner has the same >> drawback. And another one described by Gunnar in >> https://hibernate.atlassian.net/browse/OGM-469 >> >> ### The type-safe map approach >> >> This approach is vaguely similar to the Map approach except that the >> payload is >> represented and looked up by Class. This has the benefit of not having >> namespace problems and is generally less String-y. >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> T getCompanion(Class type); >> void addCompanion(Object companion); >> void removeCompanion(Class type) >> >> } >> >> >> SessionImpl { >> //could also use an array or an ArrayList >> private Map, Object> companions; >> public T getCompanion(Class type) { return (T) >> companions.get(type); } >> public void addCompanion(Object companion) { >> companions.add(companion.getClass(), type); } >> public void removeCompanion(Class type) { >> companions.remove(type); } >> } >> >> Like in the Map approach, the persister or custom event listener would >> interact >> with SessionCompanion. >> There are open issues like what should be done when two objects of the >> same >> type are added to the same session. >> Likewise the clear / close hook issues need to be addressed. >> >> ### the SessionEventListener approach >> >> I did not know but there is a concept of `SessionEventListener` which can >> be >> added to a `SessionImplementor`. It has hooks that are addressing most of >> the >> goals. >> >> >> //interface already exists >> interface SessionImplementor { >> public SessionEventListenerManager getEventListenerManager(); >> } >> >> //interface already exists >> public interface SessionEventListenerManager extends >> SessionEventListener { >> // add this method to be able to retrieve a specific listener >> holding some state for a 3rd party project >> List getSessionEventListeners(); >> } >> >> OGM or Search would implement a `SessionEventListener` and attach an >> instance to a session via `Session.addEventListeners()`. >> It would require to add a method to retrieve the list of >> `SessionEventListener`s attached to a `SessionEventListenerManager`. >> >> List listeners = >> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); >> OgmSessionEventListener ogmListener = >> findOrAddOgmListener(sessionImplementor, listeners); >> ogmListener.someStuff(); >> >> ## What about clear and close? >> >> We have a few ways to react to these. >> SessionEventListener is already called back when a flush begins / ends as >> well as when Session closes. >> We need to either: >> >> - add a clear begins / ends callback >> - have the third party project add a ClearEventListener which would >> access the SessionEventListeners and do some magic. >> >> The first approach has my preference and would do: >> >> >> public interface SessionEventListener { >> [...] >> void clearStart(); >> void clearEnd(); >> } >> >> What do you guys think? The SessionEventListener approach feels more >> natural. >> > > Tbh. I feel maintaining the state with a listener is a bit hacky. How > would we find "our" listener, I guess it would involve some ugly instanceof > check? > > The map based approaches seem preferable to me (I dislike the "companion" > naming scheme though). The type-safe map approach is nice, as you say it > may cause type collisions though and lead to a proliferation of key types. > How about a combined approach which provides one such typesafe container > per "client": > > public interface SessionAttributes { > > T get(Class type); > T put(Class type, T value); > T remove(Class type); > } > > And > > public interface SessionImplementor { > ... > SessionAttributes getAttributes(String integratorId); > } > > And in OGM: > > public static final String OGM_COMMON_ATTRIBUTES = > "org.hibernate.ogm.attributes.common"; > ... > FooBar fb = > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > This avoids collisions of attributes of the same type between different > clients such as OGM and Search (there could even be several attribute > containers used by one client). The SessionAttributes could be instantiated > lazily upon the first getAttributes() call, avoiding any overhead if the > functionality is not used. > > The clean-up part (if it is required?) could then be done by an > accompanying SessionEventListener. > > --Gunnar > > >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gunnar at hibernate.org Mon Mar 31 08:48:45 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 14:48:45 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: <46B9879B-AD1F-4FEB-9E6A-BA2C4FDAFB07@hibernate.org> References: <20140320220523.GC10878@hibernate.org> <46B9879B-AD1F-4FEB-9E6A-BA2C4FDAFB07@hibernate.org> Message-ID: 2014-03-31 14:35 GMT+02:00 Emmanuel Bernard : > Btw to answer your concern about the event listeners and the use of > instance of, we could imagine an API like getListenerOfType(Class) on the > SessionEventListenerManager. > Hum, couldn't there be several instances of the same listener type, e.g. configured differently? Maybe not in our particular case, but such API would restrict this case. > Because one key thing that this approach solves and that the map approach > does not is the actual event listener callback capability on close, flush, > etc > Yes, the map based approach would still need a listener which does these clean-up things. > > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > >> I took some more time to think about our conversation from 2 IRC meeting >> ago >> about offering the ability to carry session bound state not related to >> ORM per se. >> Below is a sum and a potential solution. >> If you are short on time, read Goals, then the SessionSessionEventListener >> approach and ignore the rest. >> >> ## Goals >> >> The goal is to be able to carry session bound state for non-ORM projects >> like search and OGM. >> We want to avoid ThreadLocal use, in particular when it cannot be >> protected by a try / catch for proper resource cleaning. >> We want to avoid a structure that would be shared across threads >> concurrently >> i.e. using ConcurrentHashMap with a Weak reference to the session. >> It needs to be informed of a call to session.clear() >> It needs to be informed of a call to session.close() >> The state needs to be accessed from event listener implementations and >> custom >> persister / loader implementations i.e. SessionImplementor and maybe >> EventSource? >> >> ## Approaches >> >> I'll discuss the approaches we explored in the meeting and then offer an >> alternative one that I think is pretty interesting and fit better with >> the current Session model. >> >> ### Map >> >> This is essentially sticking a map on SessionImpl and use it to carry >> state. >> The following is a pseudo implementation >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> Object getCompanion(String key); >> void addCompanion(String key, Object companion); >> void removeCompanion(String key); >> } >> >> >> /** >> * adds a map to the SessionImpl >> */ >> SessionImpl { >> private Map companions; >> public Object getCompanion(String key) { return >> companions.get(key); } >> public void addCompanion(String key, Object value) { >> companions.add(key, companion); } >> public void removeCompanion(String key) { companions.remove(key) } >> } >> >> The persister or event listener would call SessionCompation.*Companion >> method >> to put and retrieve its state. >> >> There is no clear / close event listener loop and it would need to be >> added. >> >> ### Delegator >> >> Gunnar and teve discussed an approach where the delegator would be passed >> to >> the underlying session and be accessible via an `unwrap` method. >> I have not followed the details but this approach has one major flaw: the >> delegator (OgmSession, FullTextSession etc) is not always created and thus >> would not be necessarily available. >> A somewhat similar idea involving passing the session owner has the same >> drawback. And another one described by Gunnar in >> https://hibernate.atlassian.net/browse/OGM-469 >> >> ### The type-safe map approach >> >> This approach is vaguely similar to the Map approach except that the >> payload is >> represented and looked up by Class. This has the benefit of not having >> namespace problems and is generally less String-y. >> >> >> /** >> * interface implemented by SessionImpl and the like >> */ >> interface SessionCompanion { >> T getCompanion(Class type); >> void addCompanion(Object companion); >> void removeCompanion(Class type) >> >> } >> >> >> SessionImpl { >> //could also use an array or an ArrayList >> private Map, Object> companions; >> public T getCompanion(Class type) { return (T) >> companions.get(type); } >> public void addCompanion(Object companion) { >> companions.add(companion.getClass(), type); } >> public void removeCompanion(Class type) { >> companions.remove(type); } >> } >> >> Like in the Map approach, the persister or custom event listener would >> interact >> with SessionCompanion. >> There are open issues like what should be done when two objects of the >> same >> type are added to the same session. >> Likewise the clear / close hook issues need to be addressed. >> >> ### the SessionEventListener approach >> >> I did not know but there is a concept of `SessionEventListener` which can >> be >> added to a `SessionImplementor`. It has hooks that are addressing most of >> the >> goals. >> >> >> //interface already exists >> interface SessionImplementor { >> public SessionEventListenerManager getEventListenerManager(); >> } >> >> //interface already exists >> public interface SessionEventListenerManager extends >> SessionEventListener { >> // add this method to be able to retrieve a specific listener >> holding some state for a 3rd party project >> List getSessionEventListeners(); >> } >> >> OGM or Search would implement a `SessionEventListener` and attach an >> instance to a session via `Session.addEventListeners()`. >> It would require to add a method to retrieve the list of >> `SessionEventListener`s attached to a `SessionEventListenerManager`. >> >> List listeners = >> sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); >> OgmSessionEventListener ogmListener = >> findOrAddOgmListener(sessionImplementor, listeners); >> ogmListener.someStuff(); >> >> ## What about clear and close? >> >> We have a few ways to react to these. >> SessionEventListener is already called back when a flush begins / ends as >> well as when Session closes. >> We need to either: >> >> - add a clear begins / ends callback >> - have the third party project add a ClearEventListener which would >> access the SessionEventListeners and do some magic. >> >> The first approach has my preference and would do: >> >> >> public interface SessionEventListener { >> [...] >> void clearStart(); >> void clearEnd(); >> } >> >> What do you guys think? The SessionEventListener approach feels more >> natural. >> > > Tbh. I feel maintaining the state with a listener is a bit hacky. How > would we find "our" listener, I guess it would involve some ugly instanceof > check? > > The map based approaches seem preferable to me (I dislike the "companion" > naming scheme though). The type-safe map approach is nice, as you say it > may cause type collisions though and lead to a proliferation of key types. > How about a combined approach which provides one such typesafe container > per "client": > > public interface SessionAttributes { > > T get(Class type); > T put(Class type, T value); > T remove(Class type); > } > > And > > public interface SessionImplementor { > ... > SessionAttributes getAttributes(String integratorId); > } > > And in OGM: > > public static final String OGM_COMMON_ATTRIBUTES = > "org.hibernate.ogm.attributes.common"; > ... > FooBar fb = > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > This avoids collisions of attributes of the same type between different > clients such as OGM and Search (there could even be several attribute > containers used by one client). The SessionAttributes could be instantiated > lazily upon the first getAttributes() call, avoiding any overhead if the > functionality is not used. > > The clean-up part (if it is required?) could then be done by an > accompanying SessionEventListener. > > --Gunnar > > >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From steve at hibernate.org Mon Mar 31 09:37:23 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 08:37:23 -0500 Subject: [hibernate-dev] Attribute paths and '.' versus '#' as separator In-Reply-To: References: Message-ID: So why is #nv (or ::nv) any different than #to (::to) or #hell (::hell)? In other words, if you agree that this or that is delimiter to use for attributes, why is it different at the start of a path versus within a path? `to` is still a method right? `hell` is still a method... On Mon, Mar 31, 2014 at 4:02 AM, Gunnar Morling wrote: > > > > 2014-03-29 17:40 GMT+01:00 Steve Ebersole : > > To wrap this up.. >> >> The most important part for me is being able to identify the point between >> the "attribute base" and the "attribute path". If we just use a separate >> delimiter there, that's enough for me. Since one of us has a preference >> for using dots within the "attribute path" part (and its irrelevant to >> me), >> I'll go with that. So: >> >> org.h.SomeEntity#nv.to.hell >> > > +1 for that. > > You might also consider to use "::" as the delimiter between base and path: > > org.h.SomeEntity::nv.to.hell > > "::" is the syntax for method references in Java 8 and it may possibly be > used for field references as well in a future Java version. So in some way > it may be nice to resemble that. > > --Gunnar > > >> >> >> >> On Fri, Mar 28, 2014 at 3:18 PM, Steve Ebersole >> wrote: >> >> > What we choose as a separator after the "pivot" is irrelevant to a >> degree, >> > especially in terms of the compatibility concern. I think you >> understood >> > that, just being clear. Meaning that calls like: >> > >> > sessionFactoryImplementor.getCollectionPersister( >> "org.h.SomeEntity.nv.to.hell" >> > ) >> > >> > will fail whether we use "org.h.SomeEntity#nv.to.hell" or >> "org.h.SomeEntity#nv#to#hell" >> > as the role key. >> > >> > As for "being natural", we'll agree to disagree. But Java has no such >> > notion as attributes so arguing about what is more natural in how Java >> > represents attribute paths is a bit moot imo. Were these all >> *accessible >> > fields*, then sure the code to access them chained would use 'dots'. >> But I >> > think its pretty plain to see how in the call I listed above: >> > >> > sessionFactoryImplementor.getCollectionPersister( >> "org.h.SomeEntity.nv.to.hell" >> > ) >> > >> > the use of '.' locks you into never being able to programatically >> > parse/understand that String structural, which I think is just very >> > limiting in many places. >> > >> > >> > >> > On Fri, Mar 28, 2014 at 1:44 PM, Emmanuel Bernard < >> emmanuel at hibernate.org>wrote: >> > >> >> No strong feeling about it. >> >> It will break the OGM dialects that make use of the collection role >> >> though. So we need to anticipate. >> >> >> >> To me . looks more like the code being used and is a natural notation >> >> even beyond Java. But I get that # offers some additional info. >> >> Have you considered? >> >> >> >> org.h.SomeEntity#nv.to.hell >> >> >> >> I think that would have my preference actually. >> >> >> >> On 27 Mar 2014, at 23:54, Steve Ebersole wrote: >> >> >> >> > This is a bit of a potentially insidious one. Not the best way to >> start >> >> > off a discussion, I know :) >> >> > >> >> > The premise is this... Until now Hibernate has represented attribute >> >> roles >> >> > using dots. For an attribute named 'department' on the >> >> com.acme.Employee >> >> > entity, the role would be "com.acme.Employee.department". In terms >> of >> >> > embeddables, say Employee had an 'address' embedded with its own >> >> attributes >> >> > like 'city'. Then, the full role for 'city' would be >> >> > "com.acme.Employee.address.city". >> >> > >> >> > As you can start to see the dots here are completely >> indistinguishable >> >> in >> >> > terms of those which define the package/class and those which >> identify >> >> the >> >> > attribute "path". >> >> > >> >> > So one of the things I started playing with in 5 is to replace the >> >> > separators used in attribute paths to use '#', such that >> >> > "com.acme.Employee.address.city" would instead be >> >> > "com.acme.Employee#address#city". This makes the role fully >> parseable >> >> > which is actually useful in quite a few situations. And it REALLY >> >> helps in >> >> > things I have just started working on like storing metadata for >> >> composites >> >> > (embeddeds/embeddables) on the SessionFactory, which is the first >> step >> >> in >> >> > support for some cool new features around embeddables like >> discriminated >> >> > inheritance support. >> >> > >> >> > However, there is a minor drawback. Like all attributes, collections >> >> have >> >> > a role. Unfortunately the use of '.' in their role Strings leaks >> into >> >> the >> >> > SPI in terms of locating the CollectionPersisters. >> >> > >> >> > So the question is whether to continue with this path of replacing >> the >> >> use >> >> > of '.' with '#' for attribute path separators. The drawback is >> >> > unfortunate. The benefit is very nice, but I can't really say it is >> >> > required atm. >> >> > >> >> > Votes? Thoughts? >> >> > _______________________________________________ >> >> > 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 steve at hibernate.org Mon Mar 31 09:46:34 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 08:46:34 -0500 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: References: <20140320220523.GC10878@hibernate.org> <46B9879B-AD1F-4FEB-9E6A-BA2C4FDAFB07@hibernate.org> Message-ID: On Mon, Mar 31, 2014 at 7:48 AM, Gunnar Morling wrote: > 2014-03-31 14:35 GMT+02:00 Emmanuel Bernard : > > > Btw to answer your concern about the event listeners and the use of > > instance of, we could imagine an API like getListenerOfType(Class) on the > > SessionEventListenerManager. > > > > Hum, couldn't there be several instances of the same listener type, e.g. > configured differently? Maybe not in our particular case, but such API > would restrict this case. > > As I mentioned on IRC weeks ago when we discussed this, there is an implication here that there be only one registered listener of type Class. At least conceptually. That can either be an explicit part of the contract (ala something like org.hibernate.event.service.spi.DuplicationStrategy) or just an implicit contract for the clients (as the one doing the registering). The return of this method would simply return the first (or last) match. > > Because one key thing that this approach solves and that the map approach > > does not is the actual event listener callback capability on close, > flush, > > etc > > > > Yes, the map based approach would still need a listener which does these > clean-up things. > > > > > > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > > > >> I took some more time to think about our conversation from 2 IRC meeting > >> ago > >> about offering the ability to carry session bound state not related to > >> ORM per se. > >> Below is a sum and a potential solution. > >> If you are short on time, read Goals, then the > SessionSessionEventListener > >> approach and ignore the rest. > >> > >> ## Goals > >> > >> The goal is to be able to carry session bound state for non-ORM projects > >> like search and OGM. > >> We want to avoid ThreadLocal use, in particular when it cannot be > >> protected by a try / catch for proper resource cleaning. > >> We want to avoid a structure that would be shared across threads > >> concurrently > >> i.e. using ConcurrentHashMap with a Weak reference to the session. > >> It needs to be informed of a call to session.clear() > >> It needs to be informed of a call to session.close() > >> The state needs to be accessed from event listener implementations and > >> custom > >> persister / loader implementations i.e. SessionImplementor and maybe > >> EventSource? > >> > >> ## Approaches > >> > >> I'll discuss the approaches we explored in the meeting and then offer an > >> alternative one that I think is pretty interesting and fit better with > >> the current Session model. > >> > >> ### Map > >> > >> This is essentially sticking a map on SessionImpl and use it to carry > >> state. > >> The following is a pseudo implementation > >> > >> > >> /** > >> * interface implemented by SessionImpl and the like > >> */ > >> interface SessionCompanion { > >> Object getCompanion(String key); > >> void addCompanion(String key, Object companion); > >> void removeCompanion(String key); > >> } > >> > >> > >> /** > >> * adds a map to the SessionImpl > >> */ > >> SessionImpl { > >> private Map companions; > >> public Object getCompanion(String key) { return > >> companions.get(key); } > >> public void addCompanion(String key, Object value) { > >> companions.add(key, companion); } > >> public void removeCompanion(String key) { > companions.remove(key) } > >> } > >> > >> The persister or event listener would call SessionCompation.*Companion > >> method > >> to put and retrieve its state. > >> > >> There is no clear / close event listener loop and it would need to be > >> added. > >> > >> ### Delegator > >> > >> Gunnar and teve discussed an approach where the delegator would be > passed > >> to > >> the underlying session and be accessible via an `unwrap` method. > >> I have not followed the details but this approach has one major flaw: > the > >> delegator (OgmSession, FullTextSession etc) is not always created and > thus > >> would not be necessarily available. > >> A somewhat similar idea involving passing the session owner has the same > >> drawback. And another one described by Gunnar in > >> https://hibernate.atlassian.net/browse/OGM-469 > >> > >> ### The type-safe map approach > >> > >> This approach is vaguely similar to the Map approach except that the > >> payload is > >> represented and looked up by Class. This has the benefit of not having > >> namespace problems and is generally less String-y. > >> > >> > >> /** > >> * interface implemented by SessionImpl and the like > >> */ > >> interface SessionCompanion { > >> T getCompanion(Class type); > >> void addCompanion(Object companion); > >> void removeCompanion(Class type) > >> > >> } > >> > >> > >> SessionImpl { > >> //could also use an array or an ArrayList > >> private Map, Object> companions; > >> public T getCompanion(Class type) { return (T) > >> companions.get(type); } > >> public void addCompanion(Object companion) { > >> companions.add(companion.getClass(), type); } > >> public void removeCompanion(Class type) { > >> companions.remove(type); } > >> } > >> > >> Like in the Map approach, the persister or custom event listener would > >> interact > >> with SessionCompanion. > >> There are open issues like what should be done when two objects of the > >> same > >> type are added to the same session. > >> Likewise the clear / close hook issues need to be addressed. > >> > >> ### the SessionEventListener approach > >> > >> I did not know but there is a concept of `SessionEventListener` which > can > >> be > >> added to a `SessionImplementor`. It has hooks that are addressing most > of > >> the > >> goals. > >> > >> > >> //interface already exists > >> interface SessionImplementor { > >> public SessionEventListenerManager getEventListenerManager(); > >> } > >> > >> //interface already exists > >> public interface SessionEventListenerManager extends > >> SessionEventListener { > >> // add this method to be able to retrieve a specific listener > >> holding some state for a 3rd party project > >> List getSessionEventListeners(); > >> } > >> > >> OGM or Search would implement a `SessionEventListener` and attach an > >> instance to a session via `Session.addEventListeners()`. > >> It would require to add a method to retrieve the list of > >> `SessionEventListener`s attached to a `SessionEventListenerManager`. > >> > >> List listeners = > >> > sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); > >> OgmSessionEventListener ogmListener = > >> findOrAddOgmListener(sessionImplementor, listeners); > >> ogmListener.someStuff(); > >> > >> ## What about clear and close? > >> > >> We have a few ways to react to these. > >> SessionEventListener is already called back when a flush begins / ends > as > >> well as when Session closes. > >> We need to either: > >> > >> - add a clear begins / ends callback > >> - have the third party project add a ClearEventListener which would > >> access the SessionEventListeners and do some magic. > >> > >> The first approach has my preference and would do: > >> > >> > >> public interface SessionEventListener { > >> [...] > >> void clearStart(); > >> void clearEnd(); > >> } > >> > >> What do you guys think? The SessionEventListener approach feels more > >> natural. > >> > > > > Tbh. I feel maintaining the state with a listener is a bit hacky. How > > would we find "our" listener, I guess it would involve some ugly > instanceof > > check? > > > > The map based approaches seem preferable to me (I dislike the "companion" > > naming scheme though). The type-safe map approach is nice, as you say it > > may cause type collisions though and lead to a proliferation of key > types. > > How about a combined approach which provides one such typesafe container > > per "client": > > > > public interface SessionAttributes { > > > > T get(Class type); > > T put(Class type, T value); > > T remove(Class type); > > } > > > > And > > > > public interface SessionImplementor { > > ... > > SessionAttributes getAttributes(String integratorId); > > } > > > > And in OGM: > > > > public static final String OGM_COMMON_ATTRIBUTES = > > "org.hibernate.ogm.attributes.common"; > > ... > > FooBar fb = > > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > > > This avoids collisions of attributes of the same type between different > > clients such as OGM and Search (there could even be several attribute > > containers used by one client). The SessionAttributes could be > instantiated > > lazily upon the first getAttributes() call, avoiding any overhead if the > > functionality is not used. > > > > The clean-up part (if it is required?) could then be done by an > > accompanying SessionEventListener. > > > > --Gunnar > > > > > >> > >> Emmanuel > >> _______________________________________________ > >> 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 steve at hibernate.org Mon Mar 31 10:28:49 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 09:28:49 -0500 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> References: <20140320220523.GC10878@hibernate.org> <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> Message-ID: Wasn't just me that said -1... My concerns are 2-fold: 1) You want ORM to manage and expose "state storage" on Session even though it does not use it. 2) You want to store state in there that isnt even Session-scoped. Rather you have state that is scoped to a flush cycle, or to a transaction, etc. Really, as I said in the IRC meeting when we discussed this[1], I really just want you guys to think through the use cases and flesh them out. Then in my opinion we start to see natural places to hook in state storage. For example, in the course of that IRC discussion we saw the need to store things at the transaction-level become more clear and it seemed to me like storing the state related to these transaction-scoped use-cases is just a bad idea plain and simple. You keep it relative to the transaction. To be honest I still have not seen that "fleshed out" discussion of use cases, so its hard for me to say how state storage SHOULD be done. But I can certainly see ways that it SHOULD NOT be done. BTW, in looking through the discussion of getSessionOwner() again, I still don't agree that was the right solution for what y'all want/need. Ultimately the problem is that SessionImpl, not your delegate, gets passed into the listeners/persisters/etc. And that happens because SessionImpl passes `this` all the time. A simple solution would be to find all the places that SessionImpl passes itself (`this`) into the places of interest (creating events, calling persisters, etc) and to instead pass the delegate via an override-able method that your delegate overriddes. For example, we have this currently on SessionImpl: @Override public void persistOnFlush(String entityName, Object object, Map copiedAlready) { firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object, this ) ); } but IIUC the following would solve your problems in an even better way: public EventSource getEventSource() { return this; } @Override public void persistOnFlush(String entityName, Object object, Map copiedAlready) { firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object, getEventSource() ) ); } and then your delegate would override this `getEventSource()` method to return itself instead. The premise here is that ultimately we'd be better served actually getting the OgmSession passed along to listeners/persisters. [1] http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard wrote: > The thing is, the map approach had a big -1 from Steve hanging on its head > :) > > > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > >> I took some more time to think about our conversation from 2 IRC > meeting ago > >> about offering the ability to carry session bound state not related to > >> ORM per se. > >> Below is a sum and a potential solution. > >> If you are short on time, read Goals, then the > SessionSessionEventListener > >> approach and ignore the rest. > >> > >> ## Goals > >> > >> The goal is to be able to carry session bound state for non-ORM projects > >> like search and OGM. > >> We want to avoid ThreadLocal use, in particular when it cannot be > >> protected by a try / catch for proper resource cleaning. > >> We want to avoid a structure that would be shared across threads > concurrently > >> i.e. using ConcurrentHashMap with a Weak reference to the session. > >> It needs to be informed of a call to session.clear() > >> It needs to be informed of a call to session.close() > >> The state needs to be accessed from event listener implementations and > custom > >> persister / loader implementations i.e. SessionImplementor and maybe > >> EventSource? > >> > >> ## Approaches > >> > >> I'll discuss the approaches we explored in the meeting and then offer an > >> alternative one that I think is pretty interesting and fit better with > >> the current Session model. > >> > >> ### Map > >> > >> This is essentially sticking a map on SessionImpl and use it to carry > >> state. > >> The following is a pseudo implementation > >> > >> > >> /** > >> * interface implemented by SessionImpl and the like > >> */ > >> interface SessionCompanion { > >> Object getCompanion(String key); > >> void addCompanion(String key, Object companion); > >> void removeCompanion(String key); > >> } > >> > >> > >> /** > >> * adds a map to the SessionImpl > >> */ > >> SessionImpl { > >> private Map companions; > >> public Object getCompanion(String key) { return > companions.get(key); } > >> public void addCompanion(String key, Object value) { > companions.add(key, companion); } > >> public void removeCompanion(String key) { > companions.remove(key) } > >> } > >> > >> The persister or event listener would call SessionCompation.*Companion > method > >> to put and retrieve its state. > >> > >> There is no clear / close event listener loop and it would need to be > added. > >> > >> ### Delegator > >> > >> Gunnar and teve discussed an approach where the delegator would be > passed to > >> the underlying session and be accessible via an `unwrap` method. > >> I have not followed the details but this approach has one major flaw: > the > >> delegator (OgmSession, FullTextSession etc) is not always created and > thus > >> would not be necessarily available. > >> A somewhat similar idea involving passing the session owner has the same > >> drawback. And another one described by Gunnar in > >> https://hibernate.atlassian.net/browse/OGM-469 > >> > >> ### The type-safe map approach > >> > >> This approach is vaguely similar to the Map approach except that the > payload is > >> represented and looked up by Class. This has the benefit of not having > >> namespace problems and is generally less String-y. > >> > >> > >> /** > >> * interface implemented by SessionImpl and the like > >> */ > >> interface SessionCompanion { > >> T getCompanion(Class type); > >> void addCompanion(Object companion); > >> void removeCompanion(Class type) > >> > >> } > >> > >> > >> SessionImpl { > >> //could also use an array or an ArrayList > >> private Map, Object> companions; > >> public T getCompanion(Class type) { return (T) > companions.get(type); } > >> public void addCompanion(Object companion) { > companions.add(companion.getClass(), type); } > >> public void removeCompanion(Class type) { > companions.remove(type); } > >> } > >> > >> Like in the Map approach, the persister or custom event listener would > interact > >> with SessionCompanion. > >> There are open issues like what should be done when two objects of the > same > >> type are added to the same session. > >> Likewise the clear / close hook issues need to be addressed. > >> > >> ### the SessionEventListener approach > >> > >> I did not know but there is a concept of `SessionEventListener` which > can be > >> added to a `SessionImplementor`. It has hooks that are addressing most > of the > >> goals. > >> > >> > >> //interface already exists > >> interface SessionImplementor { > >> public SessionEventListenerManager getEventListenerManager(); > >> } > >> > >> //interface already exists > >> public interface SessionEventListenerManager extends > SessionEventListener { > >> // add this method to be able to retrieve a specific listener > holding some state for a 3rd party project > >> List getSessionEventListeners(); > >> } > >> > >> OGM or Search would implement a `SessionEventListener` and attach an > instance to a session via `Session.addEventListeners()`. > >> It would require to add a method to retrieve the list of > `SessionEventListener`s attached to a `SessionEventListenerManager`. > >> > >> List listeners = > sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); > >> OgmSessionEventListener ogmListener = > findOrAddOgmListener(sessionImplementor, listeners); > >> ogmListener.someStuff(); > >> > >> ## What about clear and close? > >> > >> We have a few ways to react to these. > >> SessionEventListener is already called back when a flush begins / ends > as well as when Session closes. > >> We need to either: > >> > >> - add a clear begins / ends callback > >> - have the third party project add a ClearEventListener which would > access the SessionEventListeners and do some magic. > >> > >> The first approach has my preference and would do: > >> > >> > >> public interface SessionEventListener { > >> [...] > >> void clearStart(); > >> void clearEnd(); > >> } > >> > >> What do you guys think? The SessionEventListener approach feels more > natural. > > > > Tbh. I feel maintaining the state with a listener is a bit hacky. How > would we find "our" listener, I guess it would involve some ugly instanceof > check? > > > > The map based approaches seem preferable to me (I dislike the > "companion" naming scheme though). The type-safe map approach is nice, as > you say it may cause type collisions though and lead to a proliferation of > key types. How about a combined approach which provides one such typesafe > container per "client": > > > > public interface SessionAttributes { > > > > T get(Class type); > > T put(Class type, T value); > > T remove(Class type); > > } > > > > And > > > > public interface SessionImplementor { > > ... > > SessionAttributes getAttributes(String integratorId); > > } > > > > And in OGM: > > > > public static final String OGM_COMMON_ATTRIBUTES = > "org.hibernate.ogm.attributes.common"; > > ... > > FooBar fb = > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > > > This avoids collisions of attributes of the same type between different > clients such as OGM and Search (there could even be several attribute > containers used by one client). The SessionAttributes could be instantiated > lazily upon the first getAttributes() call, avoiding any overhead if the > functionality is not used. > > > > The clean-up part (if it is required?) could then be done by an > accompanying SessionEventListener. > > > > --Gunnar > > > >> > >> Emmanuel > >> _______________________________________________ > >> 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 steve at hibernate.org Mon Mar 31 10:33:56 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 09:33:56 -0500 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: http://lists.jboss.org/pipermail/hibernate-dev/2013-February/009426.html On Mon, Mar 31, 2014 at 5:16 AM, Gunnar Morling wrote: > 2014-03-31 12:08 GMT+02:00 Sanne Grinovero : > > > Since Hibernate OGM is now an implementation of JPA 2.1, doesn't it > > already require Java 7? > > > > Good point; Not sure whether JPA 2.1 per-se really requires Java 7, but I > understand as an implementation we'd be "allowed" to require Java 7 as per > the spec guidelines. So far, 6 seemed sufficient for our purposes. > > You could also decide to use Java7 for the build but not necessarily > > make use of Java7 features, as Search is an optional dependency. (but > > I also don't see a problem on moving). > > > > Yes, I thought about this as well, but it makes a difficult story to > explain (depending on whether you use JP-QL or not, and depending on the > backend you use, you may be use Java 6 or 7). I'd rather move to 7 > altogether then and keep things a bit simpler. > > > > > I would like to encourage OGM to switch to Search 5 soon though: the > > HQL parser is aligning already, and some features we're working on in > > Search are meant to improve the user experience for OGM users > > specifically (HSEARCH-1119), not least it's the version meant for > > Infinispan 7, which OGM will need to support a GridDialect over > > HotRod. And solid performance improvements as usual ;-) > > > > +1 :-) > > > > > > -- Sanne > > > > On 31 March 2014 10:40, Gunnar Morling wrote: > > > +1 > > > > > > One potential issue coming to mind is that this will require Hibernate > > OGM > > > users to work with Java 7 as well (at least when using queries via > > Hibernate > > > Search). > > > > > > When discussing the issue (for OGM) last time, we decided to stick to > > Java 6 > > > to ease OGM experiments of existing Hibernate ORM users. Personally I > > don't > > > think it's a problem, (I had wished to move OGM to Java 7 before), just > > > pointing out the fact so that there are no surprises. > > > > > > So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 > > features > > > in OGM as well. > > > > > > --Gunnar > > > > > > > > > > > > > > > 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : > > > > > >> +100 > > >> > > >> On 20 Jan 2014, at 16:21, Sanne Grinovero > wrote: > > >> > > >> > The next minor release of Apache Lucene v. 4.8 will require Java7. > > >> > > > >> > The Lucene team has highlighted many good reasons for that, > including > > >> > some excellent improvements in sorting performance and reliability > of > > >> > IO operations: nice things we'd like to take advantage of. > > >> > > > >> > Objections against baseling Hibernate Search 5 to *require* Java7 > too? > > >> > We hardly have a choice, so objections better be good ;-) > > >> > > > >> > -- Sanne > > >> > _______________________________________________ > > >> > 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 > > > > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From brmeyer at redhat.com Mon Mar 31 10:48:28 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 31 Mar 2014 10:48:28 -0400 (EDT) Subject: [hibernate-dev] Fix for the Eclipse formatter In-Reply-To: References: Message-ID: <702913369.4661757.1396277308762.JavaMail.zimbra@redhat.com> Guillaume, I corrected java-formatting.xml on https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse. Thanks for pointing that out. Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Guillaume Smet" To: "Hibernate" Sent: Friday, March 28, 2014 9:55:18 AM Subject: [hibernate-dev] Fix for the Eclipse formatter Hi, Here is a fix for the Eclipse formatter posted on the community site. Currently, it changes: x.foo(); to x. foo(); which doesn't respect the checkstyle rules. Thought it might be useful to report it as it's quite painful to have a build broken because of that. Thanks! -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Mar 31 10:52:57 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 09:52:57 -0500 Subject: [hibernate-dev] Fix for the Eclipse formatter In-Reply-To: <702913369.4661757.1396277308762.JavaMail.zimbra@redhat.com> References: <702913369.4661757.1396277308762.JavaMail.zimbra@redhat.com> Message-ID: Do we want to put these in git? On Mon, Mar 31, 2014 at 9:48 AM, Brett Meyer wrote: > Guillaume, I corrected java-formatting.xml on > https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse. > Thanks for pointing that out. > > Brett Meyer > Red Hat, Hibernate ORM > > ----- Original Message ----- > From: "Guillaume Smet" > To: "Hibernate" > Sent: Friday, March 28, 2014 9:55:18 AM > Subject: [hibernate-dev] Fix for the Eclipse formatter > > Hi, > > Here is a fix for the Eclipse formatter posted on the community site. > > Currently, it changes: > x.foo(); > to > x. foo(); > > which doesn't respect the checkstyle rules. > > Thought it might be useful to report it as it's quite painful to have > a build broken because of that. > > Thanks! > > -- > Guillaume > > _______________________________________________ > 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 brmeyer at redhat.com Mon Mar 31 11:04:38 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 31 Mar 2014 11:04:38 -0400 (EDT) Subject: [hibernate-dev] Fix for the Eclipse formatter In-Reply-To: References: <702913369.4661757.1396277308762.JavaMail.zimbra@redhat.com> Message-ID: <352428417.4684616.1396278278187.JavaMail.zimbra@redhat.com> +1 -- absolutely. It seems a few of us keep overwriting each other ;) Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Steve Ebersole" To: "Brett Meyer" Cc: "Guillaume Smet" , "Hibernate" Sent: Monday, March 31, 2014 10:52:57 AM Subject: Re: [hibernate-dev] Fix for the Eclipse formatter Do we want to put these in git? On Mon, Mar 31, 2014 at 9:48 AM, Brett Meyer wrote: > Guillaume, I corrected java-formatting.xml on > https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse. > Thanks for pointing that out. > > Brett Meyer > Red Hat, Hibernate ORM > > ----- Original Message ----- > From: "Guillaume Smet" > To: "Hibernate" > Sent: Friday, March 28, 2014 9:55:18 AM > Subject: [hibernate-dev] Fix for the Eclipse formatter > > Hi, > > Here is a fix for the Eclipse formatter posted on the community site. > > Currently, it changes: > x.foo(); > to > x. foo(); > > which doesn't respect the checkstyle rules. > > Thought it might be useful to report it as it's quite painful to have > a build broken because of that. > > Thanks! > > -- > Guillaume > > _______________________________________________ > 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 emmanuel at hibernate.org Mon Mar 31 11:09:28 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 31 Mar 2014 17:09:28 +0200 Subject: [hibernate-dev] Session and carrying 3rd party state In-Reply-To: References: <20140320220523.GC10878@hibernate.org> <3D4548CC-17A6-4009-A463-17931C142D8D@hibernate.org> Message-ID: <20140331150928.GF942@hibernate.org> Gunnar, can you lead the work on getting that set of "fleshed out" use cases. With a bit of luck we could have them by tomorrow for the meeting and discuss them there. BTW, as I said in my proposal the delegate does not work as there is not always a delegate object created. Emmanuel On Mon 2014-03-31 9:28, Steve Ebersole wrote: > Wasn't just me that said -1... > > My concerns are 2-fold: > 1) You want ORM to manage and expose "state storage" on Session even though > it does not use it. > 2) You want to store state in there that isnt even Session-scoped. Rather > you have state that is scoped to a flush cycle, or to a transaction, etc. > > Really, as I said in the IRC meeting when we discussed this[1], I really > just want you guys to think through the use cases and flesh them out. Then > in my opinion we start to see natural places to hook in state storage. For > example, in the course of that IRC discussion we saw the need to store > things at the transaction-level become more clear and it seemed to me like > storing the state related to these transaction-scoped use-cases is just a > bad idea plain and simple. You keep it relative to the transaction. > > To be honest I still have not seen that "fleshed out" discussion of use > cases, so its hard for me to say how state storage SHOULD be done. But I > can certainly see ways that it SHOULD NOT be done. > > BTW, in looking through the discussion of getSessionOwner() again, I still > don't agree that was the right solution for what y'all want/need. > Ultimately the problem is that SessionImpl, not your delegate, gets passed > into the listeners/persisters/etc. And that happens because SessionImpl > passes `this` all the time. A simple solution would be to find all the > places that SessionImpl passes itself (`this`) into the places of interest > (creating events, calling persisters, etc) and to instead pass the delegate > via an override-able method that your delegate overriddes. For example, we > have this currently on SessionImpl: > > > @Override > public void persistOnFlush(String entityName, Object object, Map > copiedAlready) { > firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object, > this ) ); > } > > but IIUC the following would solve your problems in an even better way: > > public EventSource getEventSource() { > return this; > } > > @Override > public void persistOnFlush(String entityName, Object object, Map > copiedAlready) { > firePersistOnFlush( copiedAlready, new PersistEvent( entityName, object, > getEventSource() ) ); > } > > > and then your delegate would override this `getEventSource()` method to > return itself instead. > > The premise here is that ultimately we'd be better served actually getting > the OgmSession passed along to listeners/persisters. > > > [1] > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-11-15.46.log.html > > > > On Mon, Mar 31, 2014 at 7:31 AM, Emmanuel Bernard wrote: > > > The thing is, the map approach had a big -1 from Steve hanging on its head > > :) > > > > > On 31 mars 2014, at 12:07, Gunnar Morling wrote: > > > > > > > > > > > > > > > 2014-03-20 23:05 GMT+01:00 Emmanuel Bernard : > > >> I took some more time to think about our conversation from 2 IRC > > meeting ago > > >> about offering the ability to carry session bound state not related to > > >> ORM per se. > > >> Below is a sum and a potential solution. > > >> If you are short on time, read Goals, then the > > SessionSessionEventListener > > >> approach and ignore the rest. > > >> > > >> ## Goals > > >> > > >> The goal is to be able to carry session bound state for non-ORM projects > > >> like search and OGM. > > >> We want to avoid ThreadLocal use, in particular when it cannot be > > >> protected by a try / catch for proper resource cleaning. > > >> We want to avoid a structure that would be shared across threads > > concurrently > > >> i.e. using ConcurrentHashMap with a Weak reference to the session. > > >> It needs to be informed of a call to session.clear() > > >> It needs to be informed of a call to session.close() > > >> The state needs to be accessed from event listener implementations and > > custom > > >> persister / loader implementations i.e. SessionImplementor and maybe > > >> EventSource? > > >> > > >> ## Approaches > > >> > > >> I'll discuss the approaches we explored in the meeting and then offer an > > >> alternative one that I think is pretty interesting and fit better with > > >> the current Session model. > > >> > > >> ### Map > > >> > > >> This is essentially sticking a map on SessionImpl and use it to carry > > >> state. > > >> The following is a pseudo implementation > > >> > > >> > > >> /** > > >> * interface implemented by SessionImpl and the like > > >> */ > > >> interface SessionCompanion { > > >> Object getCompanion(String key); > > >> void addCompanion(String key, Object companion); > > >> void removeCompanion(String key); > > >> } > > >> > > >> > > >> /** > > >> * adds a map to the SessionImpl > > >> */ > > >> SessionImpl { > > >> private Map companions; > > >> public Object getCompanion(String key) { return > > companions.get(key); } > > >> public void addCompanion(String key, Object value) { > > companions.add(key, companion); } > > >> public void removeCompanion(String key) { > > companions.remove(key) } > > >> } > > >> > > >> The persister or event listener would call SessionCompation.*Companion > > method > > >> to put and retrieve its state. > > >> > > >> There is no clear / close event listener loop and it would need to be > > added. > > >> > > >> ### Delegator > > >> > > >> Gunnar and teve discussed an approach where the delegator would be > > passed to > > >> the underlying session and be accessible via an `unwrap` method. > > >> I have not followed the details but this approach has one major flaw: > > the > > >> delegator (OgmSession, FullTextSession etc) is not always created and > > thus > > >> would not be necessarily available. > > >> A somewhat similar idea involving passing the session owner has the same > > >> drawback. And another one described by Gunnar in > > >> https://hibernate.atlassian.net/browse/OGM-469 > > >> > > >> ### The type-safe map approach > > >> > > >> This approach is vaguely similar to the Map approach except that the > > payload is > > >> represented and looked up by Class. This has the benefit of not having > > >> namespace problems and is generally less String-y. > > >> > > >> > > >> /** > > >> * interface implemented by SessionImpl and the like > > >> */ > > >> interface SessionCompanion { > > >> T getCompanion(Class type); > > >> void addCompanion(Object companion); > > >> void removeCompanion(Class type) > > >> > > >> } > > >> > > >> > > >> SessionImpl { > > >> //could also use an array or an ArrayList > > >> private Map, Object> companions; > > >> public T getCompanion(Class type) { return (T) > > companions.get(type); } > > >> public void addCompanion(Object companion) { > > companions.add(companion.getClass(), type); } > > >> public void removeCompanion(Class type) { > > companions.remove(type); } > > >> } > > >> > > >> Like in the Map approach, the persister or custom event listener would > > interact > > >> with SessionCompanion. > > >> There are open issues like what should be done when two objects of the > > same > > >> type are added to the same session. > > >> Likewise the clear / close hook issues need to be addressed. > > >> > > >> ### the SessionEventListener approach > > >> > > >> I did not know but there is a concept of `SessionEventListener` which > > can be > > >> added to a `SessionImplementor`. It has hooks that are addressing most > > of the > > >> goals. > > >> > > >> > > >> //interface already exists > > >> interface SessionImplementor { > > >> public SessionEventListenerManager getEventListenerManager(); > > >> } > > >> > > >> //interface already exists > > >> public interface SessionEventListenerManager extends > > SessionEventListener { > > >> // add this method to be able to retrieve a specific listener > > holding some state for a 3rd party project > > >> List getSessionEventListeners(); > > >> } > > >> > > >> OGM or Search would implement a `SessionEventListener` and attach an > > instance to a session via `Session.addEventListeners()`. > > >> It would require to add a method to retrieve the list of > > `SessionEventListener`s attached to a `SessionEventListenerManager`. > > >> > > >> List listeners = > > sessionImplementor.getSessionEventListenerManager().getEnlistedListeners(); > > >> OgmSessionEventListener ogmListener = > > findOrAddOgmListener(sessionImplementor, listeners); > > >> ogmListener.someStuff(); > > >> > > >> ## What about clear and close? > > >> > > >> We have a few ways to react to these. > > >> SessionEventListener is already called back when a flush begins / ends > > as well as when Session closes. > > >> We need to either: > > >> > > >> - add a clear begins / ends callback > > >> - have the third party project add a ClearEventListener which would > > access the SessionEventListeners and do some magic. > > >> > > >> The first approach has my preference and would do: > > >> > > >> > > >> public interface SessionEventListener { > > >> [...] > > >> void clearStart(); > > >> void clearEnd(); > > >> } > > >> > > >> What do you guys think? The SessionEventListener approach feels more > > natural. > > > > > > Tbh. I feel maintaining the state with a listener is a bit hacky. How > > would we find "our" listener, I guess it would involve some ugly instanceof > > check? > > > > > > The map based approaches seem preferable to me (I dislike the > > "companion" naming scheme though). The type-safe map approach is nice, as > > you say it may cause type collisions though and lead to a proliferation of > > key types. How about a combined approach which provides one such typesafe > > container per "client": > > > > > > public interface SessionAttributes { > > > > > > T get(Class type); > > > T put(Class type, T value); > > > T remove(Class type); > > > } > > > > > > And > > > > > > public interface SessionImplementor { > > > ... > > > SessionAttributes getAttributes(String integratorId); > > > } > > > > > > And in OGM: > > > > > > public static final String OGM_COMMON_ATTRIBUTES = > > "org.hibernate.ogm.attributes.common"; > > > ... > > > FooBar fb = > > session.getAttributes(OGM_COMMON_ATTRIBUTES).get(FooBar.class); > > > > > > This avoids collisions of attributes of the same type between different > > clients such as OGM and Search (there could even be several attribute > > containers used by one client). The SessionAttributes could be instantiated > > lazily upon the first getAttributes() call, avoiding any overhead if the > > functionality is not used. > > > > > > The clean-up part (if it is required?) could then be done by an > > accompanying SessionEventListener. > > > > > > --Gunnar > > > > > >> > > >> Emmanuel > > >> _______________________________________________ > > >> 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 Mon Mar 31 12:28:56 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 31 Mar 2014 17:28:56 +0100 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: On 31 March 2014 15:33, Steve Ebersole wrote: > http://lists.jboss.org/pipermail/hibernate-dev/2013-February/009426.html Thanks Steve. So I guess that settles it for OGM as well? (Removed all people from CC as we're changing subject) -- Sanne > > > On Mon, Mar 31, 2014 at 5:16 AM, Gunnar Morling > wrote: >> >> 2014-03-31 12:08 GMT+02:00 Sanne Grinovero : >> >> > Since Hibernate OGM is now an implementation of JPA 2.1, doesn't it >> > already require Java 7? >> > >> >> Good point; Not sure whether JPA 2.1 per-se really requires Java 7, but I >> understand as an implementation we'd be "allowed" to require Java 7 as per >> the spec guidelines. So far, 6 seemed sufficient for our purposes. >> >> You could also decide to use Java7 for the build but not necessarily >> > make use of Java7 features, as Search is an optional dependency. (but >> > I also don't see a problem on moving). >> > >> >> Yes, I thought about this as well, but it makes a difficult story to >> explain (depending on whether you use JP-QL or not, and depending on the >> backend you use, you may be use Java 6 or 7). I'd rather move to 7 >> altogether then and keep things a bit simpler. >> >> > >> > I would like to encourage OGM to switch to Search 5 soon though: the >> > HQL parser is aligning already, and some features we're working on in >> > Search are meant to improve the user experience for OGM users >> > specifically (HSEARCH-1119), not least it's the version meant for >> > Infinispan 7, which OGM will need to support a GridDialect over >> > HotRod. And solid performance improvements as usual ;-) >> > >> >> +1 :-) >> >> >> > >> > -- Sanne >> > >> > On 31 March 2014 10:40, Gunnar Morling wrote: >> > > +1 >> > > >> > > One potential issue coming to mind is that this will require Hibernate >> > OGM >> > > users to work with Java 7 as well (at least when using queries via >> > Hibernate >> > > Search). >> > > >> > > When discussing the issue (for OGM) last time, we decided to stick to >> > Java 6 >> > > to ease OGM experiments of existing Hibernate ORM users. Personally I >> > don't >> > > think it's a problem, (I had wished to move OGM to Java 7 before), >> > > just >> > > pointing out the fact so that there are no surprises. >> > > >> > > So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 >> > features >> > > in OGM as well. >> > > >> > > --Gunnar >> > > >> > > >> > > >> > > >> > > 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : >> > > >> > >> +100 >> > >> >> > >> On 20 Jan 2014, at 16:21, Sanne Grinovero >> > >> wrote: >> > >> >> > >> > The next minor release of Apache Lucene v. 4.8 will require Java7. >> > >> > >> > >> > The Lucene team has highlighted many good reasons for that, >> > >> > including >> > >> > some excellent improvements in sorting performance and reliability >> > >> > of >> > >> > IO operations: nice things we'd like to take advantage of. >> > >> > >> > >> > Objections against baseling Hibernate Search 5 to *require* Java7 >> > >> > too? >> > >> > We hardly have a choice, so objections better be good ;-) >> > >> > >> > >> > -- Sanne >> > >> > _______________________________________________ >> > >> > 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 >> > > >> > > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From brmeyer at redhat.com Mon Mar 31 15:09:19 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 31 Mar 2014 15:09:19 -0400 (EDT) Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <212789367.4835743.1396292651926.JavaMail.zimbra@redhat.com> Message-ID: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> Recently, we've been trying to clean up ORM's JIRA tickets. There are a lot of duplication, stale issues, etc. One thought was pushing all ORM 3 tickets to the "Awaiting Test Case" state and requesting a reproducer on ORM 4 or 5. They would then fall under our policy of automatically rejecting those tickets that did not receive a test case within 3 months or so. This obviously would not include new features/improvements, anything assigned to someone, etc. Here's an example filter that would be used: https://hibernate.atlassian.net/issues/?filter=14660 project = HHH AND issuetype = Bug AND status in (Open, "In Progress", Reopened, "Awaiting Test Case") AND affectedVersion in ([all ORM 3 version]) AND affectedVersion not in ([all ORM 4/5 versions]) AND assignee in (EMPTY) AND reporter not in ([core contributors]) AND updated < -90d That results in 716 tickets, providing a considerable dent. I thought it would be important to solicit other opinions. Any suggestions or alternate ideas? Anything missing from the query that might make it too aggressive? Brett Meyer Red Hat, Hibernate ORM From hardy at hibernate.org Mon Mar 31 15:40:55 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 31 Mar 2014 21:40:55 +0200 Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> Message-ID: <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> On 31 Jan 2014, at 21:09, Brett Meyer wrote: > Recently, we've been trying to clean up ORM's JIRA tickets. There are a lot of duplication, stale issues, etc. One thought was pushing all ORM 3 tickets to the "Awaiting Test Case" state and requesting a reproducer on ORM 4 or 5. They would then fall under our policy of automatically rejecting those tickets that did not receive a test case within 3 months or so. Sounds like a fair attempt to try to get a grip on all these open issues. > This obviously would not include new features/improvements, anything assigned to someone, etc. I guess you would still include some features/improvements issues, since Bug is the default issue type and some people don?t change the type even so they describe a feature/improvement. But that might not be important. ?Hardy From brmeyer at redhat.com Mon Mar 31 15:52:59 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 31 Mar 2014 15:52:59 -0400 (EDT) Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> Message-ID: <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> > I guess you would still include some features/improvements issues I'm sure some legitimate things may get caught up in this, but I'd rather try to clean things up aggressively, then re-open on a case-by-case basis. If there's something we close that the community feels strongly about, the hope is that they'll comment on it and bring it to our attention. Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Hardy Ferentschik" To: "Brett Meyer" Cc: "Hibernate" Sent: Monday, March 31, 2014 3:40:55 PM Subject: Re: [hibernate-dev] ORM 3 JIRA tickets On 31 Jan 2014, at 21:09, Brett Meyer wrote: > Recently, we've been trying to clean up ORM's JIRA tickets. There are a lot of duplication, stale issues, etc. One thought was pushing all ORM 3 tickets to the "Awaiting Test Case" state and requesting a reproducer on ORM 4 or 5. They would then fall under our policy of automatically rejecting those tickets that did not receive a test case within 3 months or so. Sounds like a fair attempt to try to get a grip on all these open issues. > This obviously would not include new features/improvements, anything assigned to someone, etc. I guess you would still include some features/improvements issues, since Bug is the default issue type and some people don?t change the type even so they describe a feature/improvement. But that might not be important. ?Hardy From steve at hibernate.org Mon Mar 31 16:01:38 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 31 Mar 2014 15:01:38 -0500 Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> Message-ID: Probably not a bad idea to write up a blog describing what we are doing and why. We could link to that in the Jira comment On Mon, Mar 31, 2014 at 2:52 PM, Brett Meyer wrote: > > I guess you would still include some features/improvements issues > > I'm sure some legitimate things may get caught up in this, but I'd rather > try to clean things up aggressively, then re-open on a case-by-case basis. > If there's something we close that the community feels strongly about, the > hope is that they'll comment on it and bring it to our attention. > > Brett Meyer > Red Hat, Hibernate ORM > > ----- Original Message ----- > From: "Hardy Ferentschik" > To: "Brett Meyer" > Cc: "Hibernate" > Sent: Monday, March 31, 2014 3:40:55 PM > Subject: Re: [hibernate-dev] ORM 3 JIRA tickets > > > On 31 Jan 2014, at 21:09, Brett Meyer wrote: > > > Recently, we've been trying to clean up ORM's JIRA tickets. There are a > lot of duplication, stale issues, etc. One thought was pushing all ORM 3 > tickets to the "Awaiting Test Case" state and requesting a reproducer on > ORM 4 or 5. They would then fall under our policy of automatically > rejecting those tickets that did not receive a test case within 3 months or > so. > > Sounds like a fair attempt to try to get a grip on all these open issues. > > > This obviously would not include new features/improvements, anything > assigned to someone, etc. > > I guess you would still include some features/improvements issues, since > Bug is the default issue type and some people don't change the type > even so they describe a feature/improvement. But that might not be > important. > > --Hardy > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Mon Mar 31 16:05:20 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 31 Mar 2014 22:05:20 +0200 Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> Message-ID: <68D61251-2309-47AA-AAF9-82ADF1B3D8D7@hibernate.org> On 31 Jan 2014, at 21:52, Brett Meyer wrote: >> I guess you would still include some features/improvements issues > > I'm sure some legitimate things may get caught up in this, but I'd rather try to clean things up aggressively, then re-open on a case-by-case basis. +1 That would be my thinking as well. > If there's something we close that the community feels strongly about, the hope is that they'll comment on it and bring it to our attention. Exactly and if not it will be unlikely that we will ever dig this issue up anyways. ?Hardy From hardy at hibernate.org Mon Mar 31 16:06:25 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 31 Mar 2014 22:06:25 +0200 Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> Message-ID: <461055F8-B061-4725-A6A4-157421325633@hibernate.org> On 31 Jan 2014, at 22:01, Steve Ebersole wrote: > Probably not a bad idea to write up a blog describing what we are doing and why. We could link to that in the Jira comment +1, also an oppertunity to blog something else than ORM release blogs ;-) From brmeyer at redhat.com Mon Mar 31 16:11:21 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 31 Mar 2014 16:11:21 -0400 (EDT) Subject: [hibernate-dev] ORM 3 JIRA tickets In-Reply-To: <461055F8-B061-4725-A6A4-157421325633@hibernate.org> References: <944961304.4838241.1396292959198.JavaMail.zimbra@redhat.com> <1095A2A7-5E69-4663-9753-D7E18F0EF669@hibernate.org> <756717593.4857958.1396295579250.JavaMail.zimbra@redhat.com> <461055F8-B061-4725-A6A4-157421325633@hibernate.org> Message-ID: <1637319301.4869337.1396296681197.JavaMail.zimbra@redhat.com> Good thoughts -- will do. If anyone has differing opinions, I'm all ears. I won't attempt this for a week or so... Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Hardy Ferentschik" To: "Steve Ebersole" Cc: "Brett Meyer" , "Hibernate" Sent: Monday, March 31, 2014 4:06:25 PM Subject: Re: [hibernate-dev] ORM 3 JIRA tickets On 31 Jan 2014, at 22:01, Steve Ebersole wrote: > Probably not a bad idea to write up a blog describing what we are doing and why. We could link to that in the Jira comment +1, also an oppertunity to blog something else than ORM release blogs ;-) From Postmaster at lists.jboss.org Mon Mar 31 17:12:19 2014 From: Postmaster at lists.jboss.org (Postmaster) Date: Mon, 31 Mar 2014 23:12:19 +0200 Subject: [hibernate-dev] Delivery Failure Message-ID: --------------------------------------------------------------------------------- The message you sent to amigosenmarcha.org/informacion was rejected because it would exceed the quota for the mailbox. The subject of the message follows: Subject: Vacancy - apply online --------------------------------------------------------------------------------- From gunnar at hibernate.org Mon Mar 31 17:51:53 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 31 Mar 2014 23:51:53 +0200 Subject: [hibernate-dev] Lucene moving to Java7 In-Reply-To: References: <39793101-49E2-4286-9A4D-F6FFEC118DFF@hibernate.org> Message-ID: 2014-03-31 18:28 GMT+02:00 Sanne Grinovero : > On 31 March 2014 15:33, Steve Ebersole wrote: > > http://lists.jboss.org/pipermail/hibernate-dev/2013-February/009426.html > > Thanks Steve. So I guess that settles it for OGM as well? > IIRC, the situation back then was a bit different. The JPA JAR could simply be made usable with Java 6 as a matter of build configuration, while now a dependency explicitly requires Java 7. Sure, we could still support running on Java 6 when not using queries (or when not using the HSEARCH based parser backend), but given that this is the default parser backend for all dialects except for MongoDB I doubt that this is of much use. Also it has been a year since then in which more projects have been migrating off 6. Anyways, we had the discussion before and agreed to stick on 6 for OGM for the time being. When going to HSEARCH 5, we'll require 7 instead in many cases. That's the effect I wanted to point out to make sure we're all aware of it. Personally I'd go for 7 altogether, but I'm fine with it either way. --Gunnar > (Removed all people from CC as we're changing subject) > -- Sanne > > > > > > > On Mon, Mar 31, 2014 at 5:16 AM, Gunnar Morling > > wrote: > >> > >> 2014-03-31 12:08 GMT+02:00 Sanne Grinovero : > >> > >> > Since Hibernate OGM is now an implementation of JPA 2.1, doesn't it > >> > already require Java 7? > >> > > >> > >> Good point; Not sure whether JPA 2.1 per-se really requires Java 7, but > I > >> understand as an implementation we'd be "allowed" to require Java 7 as > per > >> the spec guidelines. So far, 6 seemed sufficient for our purposes. > >> > >> You could also decide to use Java7 for the build but not necessarily > >> > make use of Java7 features, as Search is an optional dependency. (but > >> > I also don't see a problem on moving). > >> > > >> > >> Yes, I thought about this as well, but it makes a difficult story to > >> explain (depending on whether you use JP-QL or not, and depending on the > >> backend you use, you may be use Java 6 or 7). I'd rather move to 7 > >> altogether then and keep things a bit simpler. > >> > >> > > >> > I would like to encourage OGM to switch to Search 5 soon though: the > >> > HQL parser is aligning already, and some features we're working on in > >> > Search are meant to improve the user experience for OGM users > >> > specifically (HSEARCH-1119), not least it's the version meant for > >> > Infinispan 7, which OGM will need to support a GridDialect over > >> > HotRod. And solid performance improvements as usual ;-) > >> > > >> > >> +1 :-) > >> > >> > >> > > >> > -- Sanne > >> > > >> > On 31 March 2014 10:40, Gunnar Morling wrote: > >> > > +1 > >> > > > >> > > One potential issue coming to mind is that this will require > Hibernate > >> > OGM > >> > > users to work with Java 7 as well (at least when using queries via > >> > Hibernate > >> > > Search). > >> > > > >> > > When discussing the issue (for OGM) last time, we decided to stick > to > >> > Java 6 > >> > > to ease OGM experiments of existing Hibernate ORM users. Personally > I > >> > don't > >> > > think it's a problem, (I had wished to move OGM to Java 7 before), > >> > > just > >> > > pointing out the fact so that there are no surprises. > >> > > > >> > > So once we upgrade OGM to HSEARCH 5.x, I'd then make use of Java 7 > >> > features > >> > > in OGM as well. > >> > > > >> > > --Gunnar > >> > > > >> > > > >> > > > >> > > > >> > > 2014-03-20 19:20 GMT+01:00 Hardy Ferentschik : > >> > > > >> > >> +100 > >> > >> > >> > >> On 20 Jan 2014, at 16:21, Sanne Grinovero > >> > >> wrote: > >> > >> > >> > >> > The next minor release of Apache Lucene v. 4.8 will require > Java7. > >> > >> > > >> > >> > The Lucene team has highlighted many good reasons for that, > >> > >> > including > >> > >> > some excellent improvements in sorting performance and > reliability > >> > >> > of > >> > >> > IO operations: nice things we'd like to take advantage of. > >> > >> > > >> > >> > Objections against baseling Hibernate Search 5 to *require* Java7 > >> > >> > too? > >> > >> > We hardly have a choice, so objections better be good ;-) > >> > >> > > >> > >> > -- Sanne > >> > >> > _______________________________________________ > >> > >> > 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 > >> > > > >> > > > >> > > >> _______________________________________________ > >> 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 >