From sanne at hibernate.org Fri Jan 3 10:57:08 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 3 Jan 2014 15:57:08 +0000 Subject: [hibernate-dev] Hibernate Search 5: heavy refactoring in progress! Message-ID: Hi all, I'm heavily committing on my Lucene 4 branch. It doesn't compile yet, and many commits are "temporary scaffolding" designed to be removed at further rebase phases, so I'm NOT advising to fork it unless you want to have a look. Comments are very welcome of course :-) Also, I'm trying to iterate on previous changes while my knowledge in the new Lucene internals improves, so I'm reviewing and rewriting my history several times each day. This is my current strategy: I'm favoring quick and simple changes - when possible - to get it all to a phase in which it can compile successfully. I need it quick so to minimize the time - in which I don't have tests feedback - in which collaboration with other volunteers is harder Therefore I'm adding quite some TODO and FIXME notes, rather than opening JIRAs: my plan is to resolve all TODOs before my branch is in decent enough shape for a pull request, or for those tasks that conflict with the "minimal time" requirement will be converted in JIRAs. Among other significant changes in Lucene4, many packages have been renamed. For these, I'm crafting the patches as a form of living document of required changes, that could be helpfull for compiling a migration guide for our users; see for example the commit comment at: https://github.com/Sanne/hibernate-search/commit/036539ad432f24e47128d0a6a7aeafae350fa96c I'm primarily working on the -engine module, so that as soon as this one is looking good enough we can parallelize refactoring on dependent modules. Note that Infinispan 6.0 already supports Lucene 4, so getting "engine" converted is the only dependency to unlock work on all other modules. https://github.com/Sanne/hibernate-search/compare/evolveLucene4 - Sanne From steve at hibernate.org Mon Jan 6 14:30:30 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 06 Jan 2014 13:30:30 -0600 Subject: [hibernate-dev] JdbcSession -> DataStoreSession In-Reply-To: <20131216135536.GD23294@hibernate.org> References: <52AC9B0D.6090607@hibernate.org> <20131216073822.GC13463@hibernate.org> <52AEFF00.8090508@hibernate.org> <20131216135536.GD23294@hibernate.org> Message-ID: <52CB0456.4030609@hibernate.org> I'm thinking about just dropping this (the agnostic part) as it is not really getting any traction with or looks from the non-ORM folks. On Mon 16 Dec 2013 07:55:36 AM CST, Emmanuel Bernard wrote: > In the old (4.2) Persisters / Loaders, the ResultSet API was pretty pervasive > and passed form methods to methods. > With the Operation approach, that cannot be the case anymore. But if > that can be done, that's better for OGM. > > Also, that's a bit out of my league, but I wonder if that operation > design can lead to too much memory pressure due to more objects being > created. Maybe that's just premature optimization at this stage. > > Emmanuel > > On Mon 2013-12-16 7:24, Steve Ebersole wrote: >> The Operations are store specific. So there would be a specific Operation >> for performing a JDBC query and either extracting the results (normal use) >> or accessing the ResultSet (ScrollableResults use). There would be some >> other Operation impl(s) for doing the same against no-sql stores. Operation >> is really meant to be model an end-to-end interaction with the backing >> store. >> >> The thing that "clicked" for me was realizing that even though each back-end >> would need varying Operation impls almost all of these usages come from >> persisters and loaders which OGM already provides alternatives for. We'd >> just replace them (persisters/loaders and DataStoreSession types) in tandem. >> >> Keep in mind that the idea here is simply to centralize the binding of >> connection+transaction in various transaction scenarios and encapsulate >> handling of "flow" between them. >> >> >> >> On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote: >>> When I reviewed your work earlier last week, I had the feeling that we >>> would need to replace JdbcSession with something totally different. OGM >>> Loader / Persisters would then use that different contract. >>> >>> The idea of a generic DataStoreSession is attractive. >>> >>> But something I am not clear on is how the generic parameter of >>> Operation will be used. How can a Loader or Persister invoking >>> DataStoreSession.accept() retrieves the results? Will it be ResultSet or >>> some agnostic container too? >>> >>> Emmanuel >>> >>> On Sat 2013-12-14 11:53, Steve Ebersole wrote: >>>> As Gail and I discussed the actual API to use in this JdbcSession >>>> redesign we both liked the idea of sending Operations in to the >>>> JdbcSession rather than JdbcSession exposing a very granular, JDBC-like >>>> API. This got me to thinking that JdbcSession really could be a generic >>>> representation of a connection+transaction context for *any* back end, >>>> whether that back-end was JDBC or not. >>>> >>>> I discussed this idea a bit with Sanne on IRC. He was on board in the >>>> general sense. >>>> >>>> So this morning I spent some time re-working the code to express this >>>> concept. I just pushed this out to my repo. The main contract now is >>>> org.hibernate.resource.store.DataStoreSession. The JDBC realization of >>>> this contract is defined by >>>> org.hibernate.resource.store.jdbc.JdbcSession (which extends the >>>> DataStoreSession). >>>> >>>> The nice thing is that this all ties in seamlessly with the >>>> TransactionCoordinator. There is a notion of "resource local >>>> transactions" and "jta transactions". "resource local transactions" >>>> ultimately come from the DataStoreSession which allows integrating >>>> back-end specific notions of transactions by implementing a >>>> org.hibernate.resource.transaction.ResourceLocalTransaction for that >>>> back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction >>>> for example for JDBC). >>>> >>>> Anyway, it was a nice exercise even if y'all decide to not use this in >>>> OGM. It forced me to think about the separation between the 2 main >>>> packages (org.hibernate.resource.transaction versus >>>> org.hibernate.resource.store) and to remove the cyclic deps. >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From brmeyer at redhat.com Mon Jan 6 15:48:51 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 6 Jan 2014 15:48:51 -0500 (EST) Subject: [hibernate-dev] JdbcSession proposal In-Reply-To: <52A61356.9060102@hibernate.org> References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org> <654923050.46575364.1386362198563.JavaMail.root@redhat.com> <52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com> <52A34BDC.3080400@redhat.com> <52A61356.9060102@hibernate.org> Message-ID: <1004865248.44077624.1389041331593.JavaMail.root@redhat.com> Apologies for being late to the party. Thoughts: * As discussed with Steve on IRC today, one big pain point has been that resource management/cleanup currently involves JdbcCoordinatorImpl#xref. It maps ResultSets to a Statement instance. This was great with the old proxy system, but now needs to go away. If a JDBC driver eventually wraps the given Statement with its own impl (several do it), the keying fails and the ResultSet cleanup never happens. Scoping JDBC resources to the Operation, then closing them as soon as we're finished with them (assuming holdOpenResources == false), would mitigate this. * +1 for the "Operation API", over the granular set of boilerplate code. Also, imo, I'd overload the API methods with the specific Operation impl arguments (ex: #accept(PreparedStatementQueryOperation)), rather than only one (ex: #accept(Operation)). I tend to think it's cleaner, removing type checks, etc. I know there was already some debate about that, so just my $.02. * If you haven't already, define default Operation impls and use wherever possible? * There was some discussion comparing the difficulty of integrating each possibility into ORM. Imo, *any* of them will be difficult. Removing the proxy system was a gigantic, tedious pain. That being said, let's make sure we identify all possible future needs, including the applicability of DataStoreSession, and do them once. I'd hate to roll with something, then have to change/extend it later on. The proposal process has already been doing this, but it's worth mentioning. * Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS? * Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast. But, just want to make sure we're not overlooking something. * How would CMT fit into this? * +1 for using "transaction driving" and "transaction reacting" terms, over "in/out flow" That's just from a preliminary look -- I'll go through the code in more detail when I can. Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Steve Ebersole" To: "Scott Marlow" Cc: "hibernate-dev" Sent: Monday, December 9, 2013 2:00:38 PM Subject: Re: [hibernate-dev] JdbcSession proposal I decided on a slight conceptual change. I moved the ResourceRegistry inside the LogicalConnection. I also moved the logic for acquiring and releasing connections inside the LogicalConnection based on certain callbacks I added to LogicalConnectionImplementor (previously the JdbcSession managed the release calls on the LogicalConnection). This allowed me to (imo) clean up the "resource clean up" logic. I also added the notion of ConnectionAcquisitionMode as an alternative means of the underlying problem that ConnectionReleaseMode addressed. The idea here is to request that Connections be acquired aggressively (as opposed to lazily) and not released until the (Jdbc)Session closes. I also added quite a few code comments, as well as log statements to help "visualize" the call stack All these mentioned changes have been made in the org.hibernate.resource package. The only real divergence between org.hibernate.resource and org.hibernate.resource2 in the "other discussion" wrt the type of API to expose for performing "JDBC operations". I want to nail down this lower-level resource handling first. Then I can apply these changes to both and use 2 packages to illustrate the different granularity proposals. On 12/07/2013 10:31 AM, Steve Ebersole wrote: > > I tend to agree... > > On Dec 7, 2013 10:23 AM, "Scott Marlow" > wrote: > > On 12/06/2013 04:45 PM, Scott Marlow wrote: > > I think this is an excellent question, my preference is to > fail-fast in > some fashion. > > JTA 1.1 spec description of Transaction.setRollbackOnly(): > > " > public void setRollbackOnly() throws IllegalStateException, > SystemException > > Modify the transaction associated with the target object such > that the > only possible outcome of the transaction is to roll back the > transaction. > " > > From an EJB point of view, the EJB container will eventually > notice > that the transaction is marked for rollback only when the EJB bean > invocation completes but its not clear (to me) what this means > at the > JPA level. > > Might be worth asking the JBossTS team, this question. > > > I believe that a future EE or JPA expert group will discuss > whether applications can expect a transaction to fail-fast in the > JPA persistence provider. The discussion about this came up as > part of a TCK issue (CTS-182 related whatever that is ;) > > I'm in favor of fail-fast as soon as possible, so that the > application doesn't spend (potentially), hours before attempting > to commit the JTA transaction, only to then realize that it is > marked rollback only. This doesn't seem that much different than > detecting that the active JTA transaction has timed out. > > > On 12/06/2013 03:38 PM, Steve Ebersole wrote: > > The bigger question is whether we care. Is there really a > benefit to > continuing work when a transaction is marked for rollback > only? > > > On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: > > Hi Steve, > > Looking at the Javadoc for > javax.transaction.Transaction.registerSynchronization(Synchronization > sync), I see: > > Throws: RollbackException - Thrown to indicate that > the transaction has been marked for rollback only. > > That would make it a JTA spec requirement. > > More feedback coming... > > ----- Original Message ----- > > From: "Steve Ebersole" > > To: "hibernate-dev" > > Sent: Friday, December 6, 2013 10:07:22 AM > Subject: Re: [hibernate-dev] JdbcSession proposal > > So I'll get the ball rolling :) Here is one thing > in particular I was > hoping to start a discussion on... > > For JTA transactions we currently have a lot of > complex logic to manage > who "drives" the transaction flow into Hibernate > (in terms of Hibernate > reacting to the completion). There are > potentially 2 drivers: > 1) A JTA Synchronization registered with the JTA > system > 2) The org.hibernate.Transaction instance > > A lot of the complexity in our current code comes > from the fact that we > have a lot of attempting to handle cases in which > the JTA > Synchronization cannot be registered. So one of > the simplifications I > am wanting to make here is to say that the driver > will always be the > JTA Synchronization. So I am trying to determine > how "actual" these > cases where the "JTA Synchronization cannot be > registered" are. > > The only one that I am aware of IIRC is that JTA > Synchronization cannot > be registered on transactions that are marked for > rollback-only. I > cannot remember though if that was a specific > provider (JBossTS?) or a > JTA/JTS spec requirement. > > So the proposal I have is that for JTA cases we > always register the JTA > Synchronization and allow that to drive the > "before/after completion" > callbacks (the org.hibernate.Transaction would > still potentially manage > actually calling commit/rollback on the > TransactionManager/UserTransaction). In short, > does any one see > problems with this approach? > > > On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole > wrote: > > I found a few spare minutes to work on this a > little and move it into > the next stage with some actual interfaces, > impls and usages to help > illustrate some of the proposed concepts. > > https://github.com/sebersole/JdbcSession > > The README.md is very up-to-date and detailed. > Would be good to get > input from others. > > > P.S. I probably dislike the *Inflow naming > more than you do :) > > _______________________________________________ > 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 From sanne at hibernate.org Tue Jan 7 07:59:24 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 7 Jan 2014 12:59:24 +0000 Subject: [hibernate-dev] Hibernate Search 5: heavy refactoring in progress! In-Reply-To: References: Message-ID: And update regarding: https://github.com/Sanne/hibernate-search/compare/evolveLucene4 In case you've been poking around in the first iterations, it seemed we would break a good amount of user code. That's no longer true, and it looks like we could deliver a same-features & same-API release, at least when evaluating strictly *our* public API. Some deprecations are in place, and some SPIs had to change slightly. Regarding the Lucene code itself, it is definitely going to affect end users, as some of these are "expert" but some others are probably used by everyone (like sorting). - Sorting API changed - Similarity is different - Analyzers and Tokenizer: if you have custom ones, you basically have to rewrite them - Filters: some simple changes needed - Solr analyzer framework: unfortunately this is a non-typesafe breaking change: properties passed to the various Analyzer components have different names, and if you happen to use the old ones it will throw a runtime exception with a not-too-helpfull message. - NumericField: Lucene's API is totally different; user is "safe" if he uses our annotations but will be affected in custom FieldBridge implementations - Queries: the API to create range queries, numeric queries,... is all different. DSL users are safe. - Boost at Document level is no longer available: we can reimplement it by applying to all fields, but the rules are tricky :) If we want to do that, it's a complex refactoring. - Document API is different, as is reading of Field The good news: - stuff like FieldCache, FieldSelector, Collectors, etc.. are significantly different but we can provide all the same functionality with no API impact as we did a good job at hiding this functionality. I had to rewrite most of our code but it wasn't too tricky. - Spatial, Faceting, etc.. all migrated without too much pain. The serialization code will need to be rewritten; not only did Lucene's API change, but also several things which where simply "serializable" before (think of Fields content and options) are no longer easily serialized. Not too bad? (but I'm not done yet) From guillaume.smet at gmail.com Wed Jan 8 04:29:18 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 8 Jan 2014 10:29:18 +0100 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 Message-ID: Hi all, It's been quite a long time since I came up with lazy initialization problems in the mass indexer for the last time. Unfortunately, this time, I don't see exactly how to fix this one and I would like to ask for your advice about it. The problem is quite simple: I want to index the result of a method which invokes proxies along the way. Something like: @Field public String getInformationWithProxy() { return getField().getFieldWhichIsProxyfied().getValue(); } As the fieldWhichIsProxyfied is not unproxyfied by an objectInitializer, it doesn't have any session attached thus the lazy initialization exception. Note that the method is of course more complex than that and it mixes fields from different fields and levels so we cannot use @IndexedEmbedded. As we use it to sort the results, we cannot put the information in different fields either. All in all, we're kinda stuck with this one. Any bright idea out there? Thanks. -- Guillaume From sanne at hibernate.org Wed Jan 8 07:43:54 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 8 Jan 2014 12:43:54 +0000 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: Hi Guillaume, would you agree this looks like similar to HSEARCH-1260 ? I'd like to step back a moment and re-evaluate how we faced all these lazyinitialization issues. As far as I remember, you and your team reported (and helped fixing!) a depressingly long list of issues since approximately the migration to Hibernate ORM 4 of your applications (adopting AFAIR early betas of Search 4.2 at the time - thanks JIRA for the records). So that data point means to me that you are in the sweet spot intersection of the sets {people who reported issues} V {people who actually use a non trivial Domain model}, and in the current era it looks like we don't have many contributors matching your team on these qualities. In a previous era, when Hibernate Search was based on ORM 3.x, I was working on a different project which had an extremely complex domain model (about 400 Hibernate mapped entities, of which at least 50 where @Indexed and with fairly advanced usage of custom types, custom fieldbridges, Filters, etc...). I'm mentioning this nice domain model I had, as I'm pretty sure that all these cases where working fine back then :-) I designed and implemented the MassIndexer back then, specifically tailored for this complex domain, and it worked fine. >From the looks of all these issues, I'm pretty sure that my own model would have failed all the same tests you've described, and maybe even more. Sadly, I don't have access to the staging DB of that application anymore :-( Why I'm sharing this data points? The MassIndexer code didn't change significantly since when it worked fine on my app, so I'm thinking now that we have been fixing the wrong project. Would you agree that it looks like related to how ORM changed some internal details of how proxies and lazy collections get re-attached to ORM? We probably should *remove* all the "reattaching proxies" logic workarounds from the MassIndexer, let it fail hard and see if we can get Hibernate ORM to behave like it did with Hibernate 3. That's probably the better way of how we should have fixed these issues from the beginning. Hope I'm making sense ? It would also be great for use cases like HSEARCH-1260. Sanne On 8 January 2014 09:29, Guillaume Smet wrote: > Hi all, > > It's been quite a long time since I came up with lazy initialization > problems in the mass indexer for the last time. > > Unfortunately, this time, I don't see exactly how to fix this one and > I would like to ask for your advice about it. > > The problem is quite simple: > > I want to index the result of a method which invokes proxies along the > way. Something like: > @Field > public String getInformationWithProxy() { > return getField().getFieldWhichIsProxyfied().getValue(); > } > > As the fieldWhichIsProxyfied is not unproxyfied by an > objectInitializer, it doesn't have any session attached thus the lazy > initialization exception. > > Note that the method is of course more complex than that and it mixes > fields from different fields and levels so we cannot use > @IndexedEmbedded. > > As we use it to sort the results, we cannot put the information in > different fields either. > > All in all, we're kinda stuck with this one. > > Any bright idea out there? > > 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 Jan 8 08:07:23 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 8 Jan 2014 13:07:23 +0000 Subject: [hibernate-dev] Why backports to Hibernate Search 4.4 branch? Message-ID: I've been asked on github's review comments why I'm still backporting trivial fixes to the 4.4 branch; moving the conversation to the mailing list: We created the 4.5 branch because it was impossible to support both ORM series 4.2 and 4.3, so a 4.5 release train was highly needed to not prevent people to move onto WildFly and our latest ORM versions. Still considering that JPA 2.1 is very new, I think it's fair to state that our largest pool of users is using JPA 2.0 at present; of course I'm not counting those on very old unmaintained versions as they are unlikely to download a new version of Search or reported any issue anyway. So there still is a large interest, not least some of our very best contributors, presently using ORM 4.2 and JPA 2.0, AND actively using, debugging and reporting issues on Hibernate Search 4.4 (see for example Guillaume's email of today). Also, we have products to support for a very long term which are based on this stable 4.4 branch: backporting occasional trivial issues makes our maintenance capabilities better. We don't promise that all fixes will be backported, and we'll probably apply fixes only "as needed" by a specific request, but if there is something which is definitely broken and so trivial to fix like [1], I simply think it's easier to cherry-pick right away rather than tracking some additional TODOs ;-) It is also possible that we'll do more 4.4 releases as needed. Of course I don't wish to spend too much of our effort on it, but if it's an easy task, I don't see why we should deny it. [Finally, I'm taking organizational steps to make such releases have no impact on our time, so it's a win-win for everyone.. more news to follow] Cheers, Sanne 1 - https://github.com/Sanne/hibernate-search/commit/f34a61e90b7dbec38a01f0a7d612e21423ba0e58 From guillaume.smet at gmail.com Wed Jan 8 08:13:26 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 8 Jan 2014 14:13:26 +0100 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: Hi Sanne, On Wed, Jan 8, 2014 at 1:43 PM, Sanne Grinovero wrote: > As far as I remember, you and your team reported (and helped fixing!) > a depressingly long list of issues since approximately the migration > to Hibernate ORM 4 of your applications (adopting AFAIR early betas of > Search 4.2 at the time - thanks JIRA for the records). > So that data point means to me that you are in the sweet spot > intersection of the sets {people who reported issues} V {people who > actually use a non trivial Domain model}, and in the current era it > looks like we don't have many contributors matching your team on these > qualities. We started contributing before the 4.x era but, after taking a look at the bugs we reported, I agree that the lazy initialization exceptions series started with 4.x. And AFAIR, I was quite surprised to find those bugs back then. I thought it was because we were working on more complex projects but you might be right about the fact that they were not present before. > Why I'm sharing this data points? > The MassIndexer code didn't change significantly since when it worked > fine on my app, so I'm thinking now that we have been fixing the wrong > project. Would you agree that it looks like related to how ORM changed > some internal details of how proxies and lazy collections get > re-attached to ORM? That's what I thought this morning while poking this issue although my thoughts were not as clear as yours. We installed workarounds in the mass indexer for a lot of cases but our current problem isn't fixable with a workaround AFAICS. Maybe there's something wrong/missing in the way the mass indexer is initializing the Hibernate session stuff or something we cannot do with the new 4.x architecture. Anyway, it might be a good idea to have the thoughts of an ORM guy about this. This looks like long term work so if anyone has any idea on how we can make our code work, it would be much appreciated. -- Guilllaume From sanne at hibernate.org Sun Jan 12 19:06:40 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 13 Jan 2014 00:06:40 +0000 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: Hi Guillaume, sorry I wanted to POC the following idea before replying, but couldn't get to it yet, so rather than keeping you in the dark for longer I'll share the idea: maybe you can try it yourself? What you could try is to merge the second and first phases of the MassIndexer into a single phase, so that you don't need to lock the loaded entity again to "re-attach" it to the Session. There currently is this pipeline, I guess you're familiar with it: 1- an initial phase of loading a stream of primary keys 2- transformation from batches of keys to batches of entitties 3- DocumentBuilder phase, which implicitly triggers all custom fieldbridges and processes recursively all @IndexedEmbedded 4- Feeding it all to the backend, which applies it to the IndexWriters Phase 1 is rather ok; Phase 2 is also quite simple; Phase 3 is "tricky" because it needs to attach the state which was disconnected from the Session used by threads in Phase 2.. and this is where we get in trouble as apparently the old trick of using a Lock mode is not too reliable (anymore?) This pipeline was designed this way for various performance reasons, but I suspect that merging Phase 2 and 3 in one could nowadays be relatively as fast (as other things changed and some of the original design decisions aren't necessarily applicable anymore). When you merge these phases, the idea is of course that you use a single Session to load the primary key to an entity AND transform it fully using the DocumentBuilder, only after that you clear the Session for the current batch. Then, you can remove all the previous workarounds too: given we'd be removing the re-attach processing and all the proxy re-attaching code, it might even win you something in performance.. I don't know that for sure, but seems worth to try out? Cheers, Sanne On 8 January 2014 13:13, Guillaume Smet wrote: > Hi Sanne, > > On Wed, Jan 8, 2014 at 1:43 PM, Sanne Grinovero wrote: >> As far as I remember, you and your team reported (and helped fixing!) >> a depressingly long list of issues since approximately the migration >> to Hibernate ORM 4 of your applications (adopting AFAIR early betas of >> Search 4.2 at the time - thanks JIRA for the records). >> So that data point means to me that you are in the sweet spot >> intersection of the sets {people who reported issues} V {people who >> actually use a non trivial Domain model}, and in the current era it >> looks like we don't have many contributors matching your team on these >> qualities. > > We started contributing before the 4.x era but, after taking a look at > the bugs we reported, I agree that the lazy initialization exceptions > series started with 4.x. > > And AFAIR, I was quite surprised to find those bugs back then. I > thought it was because we were working on more complex projects but > you might be right about the fact that they were not present before. > >> Why I'm sharing this data points? >> The MassIndexer code didn't change significantly since when it worked >> fine on my app, so I'm thinking now that we have been fixing the wrong >> project. Would you agree that it looks like related to how ORM changed >> some internal details of how proxies and lazy collections get >> re-attached to ORM? > > That's what I thought this morning while poking this issue although my > thoughts were not as clear as yours. We installed workarounds in the > mass indexer for a lot of cases but our current problem isn't fixable > with a workaround AFAICS. > > Maybe there's something wrong/missing in the way the mass indexer is > initializing the Hibernate session stuff or something we cannot do > with the new 4.x architecture. > > Anyway, it might be a good idea to have the thoughts of an ORM guy about this. > > This looks like long term work so if anyone has any idea on how we can > make our code work, it would be much appreciated. > > -- > Guilllaume From guillaume.smet at gmail.com Mon Jan 13 05:01:53 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 13 Jan 2014 11:01:53 +0100 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: Hi Sanne, On Mon, Jan 13, 2014 at 1:06 AM, Sanne Grinovero wrote: > Then, you can remove all the previous workarounds too: given we'd be > removing the re-attach processing and all the proxy re-attaching code, > it might even win you something in performance.. I don't know that for > sure, but seems worth to try out? I agree that the separation of work between 2 phases seems to be the root of all evil and we might be able to simplify a lot of code by removing this. I'm kinda swamped atm but I would like to take a look at this in february if it's OK with you? I will probably need some guidance. -- Guillaume From sanne at hibernate.org Mon Jan 13 18:06:35 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 14 Jan 2014 00:06:35 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly Message-ID: Hello, as you might already know by following the WildFly developer's mailing list, most of the Hibernate Search jars and dependencies (Lucene) are now included in the application server as modules. This was not primarily driven by practical need of Hibernate users but rather because of clustering needs of the application server, and also CapeDwarf and other projects make extensive use of it. Just a couple of small adjustments are needed to make it possible for Hibernate users to also take advantage of it, so I'd think we should make these adjustments to make it more useful? This is what I'm thinking: - The hibernate-search-orm jar is missing (an essential jar for our purposes) -> add a module - No additional analyzers are included -> see how optional modules work, so that - while we won't ship all those dependencies - it's still easy to add when you need one - Jipijapa should help? -> should we make Hibernate Search available to deployments whenever Hibernate ORM is made available? - Get it to a reasonable version: it's including 4.5.0.Alpha2 now -> we need to release a Beta soon, any volunteer? I'm stuck on an island with extremely slow connectivity. - Contribute some integration tests to WildFly: there aren't any today verifying the included modules What shall we do about our modules distribution? I think it would be nice to continue maintaining that, so that we can make frequent releases and that would allow users to use a different version than what they would get in WildFly - if they want to. -- Sanne From sanne at hibernate.org Mon Jan 13 18:11:58 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 14 Jan 2014 00:11:58 +0100 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: On 13 January 2014 11:01, Guillaume Smet wrote: > Hi Sanne, > > On Mon, Jan 13, 2014 at 1:06 AM, Sanne Grinovero wrote: >> Then, you can remove all the previous workarounds too: given we'd be >> removing the re-attach processing and all the proxy re-attaching code, >> it might even win you something in performance.. I don't know that for >> sure, but seems worth to try out? > > I agree that the separation of work between 2 phases seems to be the > root of all evil and we might be able to simplify a lot of code by > removing this. > > I'm kinda swamped atm but I would like to take a look at this in > february if it's OK with you? I will probably need some guidance. Of course I'm ok with that. If any I was under the impression you needed a solution urgently; if that's the case, be aware I suspect this could be a trivial change. -- Sanne From guillaume.smet at gmail.com Tue Jan 14 04:09:42 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 14 Jan 2014 10:09:42 +0100 Subject: [hibernate-dev] Mass indexer and lazy initialization exceptions S03E04 In-Reply-To: References: Message-ID: On Tue, Jan 14, 2014 at 12:11 AM, Sanne Grinovero wrote: > Of course I'm ok with that. If any I was under the impression you > needed a solution urgently; if that's the case, be aware I suspect > this could be a trivial change. It's for a sort on a table (but an important one) so I can make the customer wait if I mention a solution in the near future. I also suspect a trivial change but I think the cleanup might take more time. -- Guillaume From hardy at hibernate.org Tue Jan 14 05:23:01 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 14 Jan 2014 11:23:01 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: References: Message-ID: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> On 14 Jan 2014, at 00:06, Sanne Grinovero wrote: > as you might already know by following the WildFly developer's mailing > list, most of the Hibernate Search jars and dependencies (Lucene) are > now included in the application server as modules. Right. Still not sure whether this is such a great idea, but I guess it is too late. > Just a couple of small adjustments are needed to make it possible for > Hibernate users to also take advantage of it, so I'd think we should > make these adjustments to make it more useful? > > This is what I'm thinking: > - The hibernate-search-orm jar is missing (an essential jar for our purposes) > -> add a module +1 Does this really need a separate module? > - No additional analyzers are included > -> see how optional modules work, so that - while we won't ship all > those dependencies - it's still easy to add when you need one Is there some info about ?optional? modules? I find information about modules in general hard to find. > - Jipijapa should help? > -> should we make Hibernate Search available to deployments > whenever Hibernate ORM is made available? Per default? So if there are no indexed entities nothing happens and if there are Search gets automatically enabled? Is this what you are saying? > - Get it to a reasonable version: it's including 4.5.0.Alpha2 now > -> we need to release a Beta soon, any volunteer? I'm stuck on an > island with extremely slow connectivity. I can do a release. Just wondering whether it should be a CR already? The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out. We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks. > - Contribute some integration tests to WildFly: there aren't any > today verifying the included modules +1 > What shall we do about our modules distribution? I think it would be > nice to continue maintaining that, so that we can make frequent > releases and that would allow users to use a different version than > what they would get in WildFly - if they want to. Not sure. The module won?t be a pure drop-in anymore. Now the module needs to make sure that existing module(s) get properly ?reconfigured?. What I mean is that we might have to do more than extracting a tar ball. We might need to remove/change existing files as well. Is it not easier to provide instructions on how to update the exiting modules? Unfortunately, this comes at a non optimal point in time. Not only will it take time from the Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will get very quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of dependencies change at this point. It won?t be a simple replace of a single jar. Will/Can CapeDwarf and clustering also switch to Search 5 once we start making releases? ?Hardy From sanne at hibernate.org Tue Jan 14 06:25:42 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 14 Jan 2014 12:25:42 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> References: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> Message-ID: On 14 January 2014 11:23, Hardy Ferentschik wrote: > > On 14 Jan 2014, at 00:06, Sanne Grinovero wrote: > >> as you might already know by following the WildFly developer's mailing >> list, most of the Hibernate Search jars and dependencies (Lucene) are >> now included in the application server as modules. > > Right. Still not sure whether this is such a great idea, but I guess it is too late. Not sure either, but worst case we have our own release, so there probably are no negative aspects (?). More on this below. >> Just a couple of small adjustments are needed to make it possible for >> Hibernate users to also take advantage of it, so I'd think we should >> make these adjustments to make it more useful? >> >> This is what I'm thinking: >> - The hibernate-search-orm jar is missing (an essential jar for our purposes) >> -> add a module > > +1 Does this really need a separate module? It's probably not strictly needed, but I think it's preferable so that people can use a different version of it. Also, it's our tested configuration. >> - No additional analyzers are included >> -> see how optional modules work, so that - while we won't ship all >> those dependencies - it's still easy to add when you need one > > Is there some info about ?optional? modules? I find information about modules > in general hard to find. I wasn't aware of it either, I just learned about it in the face to face meeting. Need to try it out though.. > >> - Jipijapa should help? >> -> should we make Hibernate Search available to deployments >> whenever Hibernate ORM is made available? > > Per default? So if there are no indexed entities nothing happens and if there are > Search gets automatically enabled? Is this what you are saying? Yes. Should be great for usability. > >> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now >> -> we need to release a Beta soon, any volunteer? I'm stuck on an >> island with extremely slow connectivity. > > I can do a release. Just wondering whether it should be a CR already? > The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now > to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out. > We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks. We also have the Infinispan indexmanager on the roadmap. All work was done a year ago already, and the Infinispan issues which prevented me to merge it at the time are fixed, so I should only need to rebase it. I would love to merge it, but let's set a deadline for it.. if I can't make it we release without it again :-( Also I'm worried about HSEARCH-1260 and Guillaume's report. It would be nice to get rid of those issues by applying the cleanup I've suggested on that thread. I fundamentally agree that if we don't address these quickly, we should aim at a quick Final, still let's not rush it too much as WildFly doesn't stricly need a Final from us (or at least I wasn't asked for one). > >> - Contribute some integration tests to WildFly: there aren't any >> today verifying the included modules > > +1 > >> What shall we do about our modules distribution? I think it would be >> nice to continue maintaining that, so that we can make frequent >> releases and that would allow users to use a different version than >> what they would get in WildFly - if they want to. > > Not sure. The module won?t be a pure drop-in anymore. Now the module needs > to make sure that existing module(s) get properly ?reconfigured?. What I mean is that > we might have to do more than extracting a tar ball. We might need to remove/change > existing files as well. Is it not easier to provide instructions on how to update the exiting modules? Changing existing modules is highly discouraged and creates problems to potentially deploying other frameworks who depend on it: there should be a way to override the version that a specific deployment wants to use. This way, we can make it a "pure drop-in", without changing any existing files. > Unfortunately, this comes at a non optimal point in time. Not only will it take time from the > Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will get very > quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of dependencies > change at this point. It won?t be a simple replace of a single jar +1, that's why I think we should keep _also_ releasing our own modules. > Will/Can CapeDwarf and clustering also switch to Search 5 once we start making releases? We're going to make it very interesting for them, so I'm sure they'll find a solution :-) Very likely, next version of WildFly will use 5, but now that it's approaching a Final version, it's probably not too bad that we provide a stable version. -- Sanne > > ?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 Jan 14 06:41:01 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 14 Jan 2014 12:41:01 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: References: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> Message-ID: On 14 Jan 2014, at 12:25, Sanne Grinovero wrote: >> +1 Does this really need a separate module? > > It's probably not strictly needed, but I think it's preferable so that > people can use a different version of it. > Also, it's our tested configuration. ok >> Is there some info about ?optional? modules? I find information about modules >> in general hard to find. > > I wasn't aware of it either, I just learned about it in the face to > face meeting. > Need to try it out though.. Reminds me of JBoss Logging. How are users supposed to understand all this, if even between developers the only form of information is by word of mouth. >>> - Jipijapa should help? >>> -> should we make Hibernate Search available to deployments >>> whenever Hibernate ORM is made available? >> >> Per default? So if there are no indexed entities nothing happens and if there are >> Search gets automatically enabled? Is this what you are saying? > > Yes. Should be great for usability. +1 >> I can do a release. Just wondering whether it should be a CR already? >> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now >> to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out. >> We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks. > > We also have the Infinispan indexmanager on the roadmap. All work was > done a year ago already, and the Infinispan issues which prevented me > to merge it at the time are fixed, so I should only need to rebase it. > > I would love to merge it, but let's set a deadline for it.. if I can't > make it we release without it again :-( > > Also I'm worried about HSEARCH-1260 and Guillaume's report. It would > be nice to get rid of those issues by applying the cleanup I've > suggested on that thread. > > I fundamentally agree that if we don't address these quickly, we > should aim at a quick Final, still let's not rush it too much as > WildFly doesn't stricly need a Final from us (or at least I wasn't > asked for one). Don?t you think that a lot of users might hold of an upgrade, because they want a final or at least CR release? If we want people to use 4.5 we might need to give them a final sooner than later. I don?t see the mentioned issues addressed in the near future. Guillaume for example won?t be able to look at the mass indexer until some time February. Is it in this case not better to do a 4.5.0.Final and then add the mentioned features in a 4.5.x release? >>> What shall we do about our modules distribution? I think it would be >>> nice to continue maintaining that, so that we can make frequent >>> releases and that would allow users to use a different version than >>> what they would get in WildFly - if they want to. >> >> Not sure. The module won?t be a pure drop-in anymore. Now the module needs >> to make sure that existing module(s) get properly ?reconfigured?. What I mean is that >> we might have to do more than extracting a tar ball. We might need to remove/change >> existing files as well. Is it not easier to provide instructions on how to update the exiting modules? > > Changing existing modules is highly discouraged and creates problems > to potentially deploying other frameworks who depend on it: there > should be a way to override the version that a specific deployment > wants to use. ?Should?!? LOL. Is this via jboss-deployment-strucure? I guess we would at least somehow change the module names on our side to avoid conflicts with the wildfly provided ones. TBH, I am not a big fan of this. If I were a user, I?d rather update the existing modules, instead of adding new ones and needing to add magic xml files. ?Hardy From ales.justin at gmail.com Tue Jan 14 08:45:13 2014 From: ales.justin at gmail.com (Ales Justin) Date: Tue, 14 Jan 2014 14:45:13 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> References: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> Message-ID: > Unfortunately, this comes at a non optimal point in time. Not only will it take time from the > Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will get very > quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of dependencies > change at this point. It won?t be a simple replace of a single jar. You can always have more then one version of the "same" module. By default we call it "main", but in this case you could add "5", and then it's up to whoever to use what it wants. If they will let you "bloat" WF even more. :-) > Will/Can CapeDwarf and clustering also switch to Search 5 once we start making releases? I'm always open to suggestions. If things work and have better performance, why not. For us API means GAE API, everything else is impl detail, hence easy to change. Atm what we lack is better projections handling and distinct queries. -Ales From smarlow at redhat.com Tue Jan 14 09:46:46 2014 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 14 Jan 2014 09:46:46 -0500 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: References: Message-ID: <52D54DD6.9000803@redhat.com> I am a big fan of Hibernate technologies and the search capabilities. I am concerned though that we are deferring how to untangle the Hibernate Search/Infinispan/WildFly dependencies. I raised a few questions on the wildfly-dev mailing list, some that got answered but one important issue didn't. The question is about scheduling and how to coordinate the WildFly/Hibernate ORM/Hibernate Search/Infinispan releases such that if one component breaks the others at the end of a release cycle, how to deal with that. This isn't really my problem as I don't schedule any of these components but it would be wrong of me not to point this out. Are there any infinispan-dev mailing list threads discussing how to remove the Infinispan dependency on Hibernate Search in 2014, so that we aren't forced into keeping Hibernate Search in WildFly 9? On 01/13/2014 06:06 PM, Sanne Grinovero wrote: > Hello, > as you might already know by following the WildFly developer's mailing > list, most of the Hibernate Search jars and dependencies (Lucene) are > now included in the application server as modules. > > This was not primarily driven by practical need of Hibernate users but > rather because of clustering needs of the application server, and also > CapeDwarf and other projects make extensive use of it. > > Just a couple of small adjustments are needed to make it possible for > Hibernate users to also take advantage of it, so I'd think we should > make these adjustments to make it more useful? > > This is what I'm thinking: > - The hibernate-search-orm jar is missing (an essential jar for our purposes) > -> add a module > - No additional analyzers are included > -> see how optional modules work, so that - while we won't ship all > those dependencies - it's still easy to add when you need one > - Jipijapa should help? Jipijapa could help standardize how WildFly integrates with search providers. I'm not sure if this is needed. > -> should we make Hibernate Search available to deployments > whenever Hibernate ORM is made available? Would this slow deployment down at all for applications that don't use Hibernate Search? > - Get it to a reasonable version: it's including 4.5.0.Alpha2 now > -> we need to release a Beta soon, any volunteer? I'm stuck on an > island with extremely slow connectivity. > - Contribute some integration tests to WildFly: there aren't any > today verifying the included modules > > What shall we do about our modules distribution? I think it would be > nice to continue maintaining that, so that we can make frequent > releases and that would allow users to use a different version than > what they would get in WildFly - if they want to. > > -- Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Jan 15 04:29:24 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 15 Jan 2014 10:29:24 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: <52D54DD6.9000803@redhat.com> References: <52D54DD6.9000803@redhat.com> Message-ID: On 14 January 2014 15:46, Scott Marlow wrote: > I am a big fan of Hibernate technologies and the search capabilities. I am > concerned though that we are deferring how to untangle the Hibernate > Search/Infinispan/WildFly dependencies. > > I raised a few questions on the wildfly-dev mailing list, some that got > answered but one important issue didn't. The question is about scheduling > and how to coordinate the WildFly/Hibernate ORM/Hibernate Search/Infinispan > releases such that if one component breaks the others at the end of a > release cycle, how to deal with that. This isn't really my problem as I > don't schedule any of these components but it would be wrong of me not to > point this out. We'll try to coordinate version compatibility across projects; We do control the version being used in Infinispan and will keep it up to date as there are various good reasons to do that. The tricky part is that we don't control necessarily which versions of ORM and Infinispan are going to be picked in a specific WildFly release, but optimistically speaking I expect that this choice will always be at "same generation". To address the more pessimistic scenario, we'll need to be more flexible in having +1 / -1 version compatibility at SPI levels. Historically we'll have been quite good at keeping a level of flexibility, but you're right it is a concern and we'll be handling stricter compatibility checks via new CI jobs. Worst case, we'll always be able to deploy additional modules. > > Are there any infinispan-dev mailing list threads discussing how to remove > the Infinispan dependency on Hibernate Search in 2014, so that we aren't > forced into keeping Hibernate Search in WildFly 9? Not yet, if any now that it's being included I think it should stay there. A major release is a big change for our point of view but not a reason to completely disrupt users's experience, from their point of view it's not nice that the way to deploy something like this changes *that* frequently. > > > On 01/13/2014 06:06 PM, Sanne Grinovero wrote: >> >> Hello, >> as you might already know by following the WildFly developer's mailing >> list, most of the Hibernate Search jars and dependencies (Lucene) are >> now included in the application server as modules. >> >> This was not primarily driven by practical need of Hibernate users but >> rather because of clustering needs of the application server, and also >> CapeDwarf and other projects make extensive use of it. >> >> Just a couple of small adjustments are needed to make it possible for >> Hibernate users to also take advantage of it, so I'd think we should >> make these adjustments to make it more useful? >> >> This is what I'm thinking: >> - The hibernate-search-orm jar is missing (an essential jar for our >> purposes) >> -> add a module >> - No additional analyzers are included >> -> see how optional modules work, so that - while we won't ship all >> those dependencies - it's still easy to add when you need one >> - Jipijapa should help? > > > Jipijapa could help standardize how WildFly integrates with search > providers. I'm not sure if this is needed. I mean, I think it's probably Jipijapa's responsibility to inject the module on the classpath for Hibernate users. > > >> -> should we make Hibernate Search available to deployments >> whenever Hibernate ORM is made available? > > > Would this slow deployment down at all for applications that don't use > Hibernate Search? No, not at all. Sanne >> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now >> -> we need to release a Beta soon, any volunteer? I'm stuck on an >> island with extremely slow connectivity. >> - Contribute some integration tests to WildFly: there aren't any >> today verifying the included modules >> >> What shall we do about our modules distribution? I think it would be >> nice to continue maintaining that, so that we can make frequent >> releases and that would allow users to use a different version than >> what they would get in WildFly - if they want to. >> >> -- Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Wed Jan 15 08:17:34 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 15 Jan 2014 07:17:34 -0600 Subject: [hibernate-dev] irc team meetings and jbott Message-ID: <52D68A6E.8040604@hibernate.org> We have been having a lot of trouble lately with relying on jbott to record the team meetings on irc. A few times jbott has not been in the room. A few times it refuses to start/end meetings. Max, is there anything to be done to make jbott more stable? If not, do we maybe want to look at using gitter for team meetings? We would not be able to delineate meetings (unless they have added that feature), but we would at least have the notes persistent. Any other thoughts? From steve at hibernate.org Wed Jan 15 08:27:54 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 15 Jan 2014 07:27:54 -0600 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: <52D68A6E.8040604@hibernate.org> References: <52D68A6E.8040604@hibernate.org> Message-ID: <52D68CDA.606@hibernate.org> On queue :) [07:25] <-- jbott has left this server (Ping timeout: 276 seconds). On Wed 15 Jan 2014 07:17:34 AM CST, Steve Ebersole wrote: > We have been having a lot of trouble lately with relying on jbott to > record the team meetings on irc. A few times jbott has not been in > the room. A few times it refuses to start/end meetings. > > Max, is there anything to be done to make jbott more stable? > > If not, do we maybe want to look at using gitter for team meetings? We > would not be able to delineate meetings (unless they have added that > feature), but we would at least have the notes persistent. > > Any other thoughts? From hardy at hibernate.org Wed Jan 15 15:55:18 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 15 Jan 2014 21:55:18 +0100 Subject: [hibernate-dev] Haste makes waste - here comes Hibernate Validator 5.1.0.Beta1 Message-ID: Hibernate Validator 5.1.0.Beta1is out. More info on in.relation.to - http://in.relation.to/24788.lace ?Hardy From hardy at hibernate.org Wed Jan 15 16:17:06 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 15 Jan 2014 22:17:06 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: References: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> Message-ID: <455C9FE6-C8ED-41B3-93CB-D538AB6BDA37@hibernate.org> >>> I can do a release. Just wondering whether it should be a CR already? >>> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now >>> to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out. >>> We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks. >> >> We also have the Infinispan indexmanager on the roadmap. All work was >> done a year ago already, and the Infinispan issues which prevented me >> to merge it at the time are fixed, so I should only need to rebase it. >> >> I would love to merge it, but let's set a deadline for it.. if I can't >> make it we release without it again :-( >> >> Also I'm worried about HSEARCH-1260 and Guillaume's report. It would >> be nice to get rid of those issues by applying the cleanup I've >> suggested on that thread. >> >> I fundamentally agree that if we don't address these quickly, we >> should aim at a quick Final, still let's not rush it too much as >> WildFly doesn't stricly need a Final from us (or at least I wasn't >> asked for one). > > Don?t you think that a lot of users might hold of an upgrade, because they want a final > or at least CR release? If we want people to use 4.5 we might need to give them > a final sooner than later. I don?t see the mentioned issues addressed in the near > future. Guillaume for example won?t be able to look at the mass indexer until some > time February. Is it in this case not better to do a 4.5.0.Final and then add the > mentioned features in a 4.5.x release? Have we decided on a version? Sanne, you still vote for a 4.5 Beta1? ?Hardy From steve at hibernate.org Wed Jan 15 17:27:14 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 15 Jan 2014 16:27:14 -0600 Subject: [hibernate-dev] JdbcSession proposal In-Reply-To: <1004865248.44077624.1389041331593.JavaMail.root@redhat.com> References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org> <654923050.46575364.1386362198563.JavaMail.root@redhat.com> <52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com> <52A34BDC.3080400@redhat.com> <52A61356.9060102@hibernate.org> <1004865248.44077624.1389041331593.JavaMail.root@redhat.com> Message-ID: <52D70B42.5020307@hibernate.org> See inline... P.S. Latest revs pushed to my upstream repo On 01/06/2014 02:48 PM, Brett Meyer wrote: > * +1 for the "Operation API", over the granular set of boilerplate code. Also, imo, I'd overload the API methods with the specific Operation impl arguments (ex: #accept(PreparedStatementQueryOperation)), rather than only one (ex: #accept(Operation)). I tend to think it's cleaner, removing type checks, etc. I know there was already some debate about that, so just my $.02. Operation is a "free flow" contract much like Work. Not sure what kind of "concrete impls" you see. Maybe you are thinking of the OperationSpec concept... But even for OperationSpec I am not sure overloading the methods is a good idea. I generally consider exploding an API 1+1 for new types is an anti-pattern. Let's just let the API evolve as we move further in the design and not force stuff up front... > * If you haven't already, define default Operation impls and use wherever possible? Again, I think you are thinking of OperationSpec... > * There was some discussion comparing the difficulty of integrating each possibility into ORM. Imo, *any* of them will be difficult. Removing the proxy system was a gigantic, tedious pain. That being said, let's make sure we identify all possible future needs, including the applicability of DataStoreSession, and do them once. I'd hate to roll with something, then have to change/extend it later on. The proposal process has already been doing this, but it's worth mentioning. Not sure this is accurate. The "low-level API" is much closer to JDBC and would be much easier to swap in than the Operation-style approaches. Trivial? No, just much easier. As far as DataStoreSession, I've already reverted that work. There was no interest from those who it would have benefitted and it just muddied the waters for straight JDBC usage. And I whole-heartedly agree that I consider this as "that ship has sailed"; meaning I will not be going back and changing JdbcSession to an agnostic DataStoreSession down the road. While it would have been nice to do up-front, it would be just too much work to add on later. > * Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS? > * Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast. But, just want to make sure we're not overlooking something. Yep. I have discussed with Tom a few times. Scott and I are doing one last round of discussion with him just to re-re-re-confirm. > * How would CMT fit into this? Don't understand the question. From karl+hibernate at xk72.com Thu Jan 16 03:42:31 2014 From: karl+hibernate at xk72.com (Karl von Randow) Date: Thu, 16 Jan 2014 21:42:31 +1300 Subject: [hibernate-dev] Standalone service registry Message-ID: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> Hi all, I had a conversation with Steve today on IRC about refactoring the org.hibernate.service package to make it standalone. The service registry implementation is mostly separable from Hibernate core already, and it could be useful in other applications perhaps where hibernate-core isn?t a dependency. I found myself in that exact situation, which is why I?m here. I have done a test extraction of the service registry classes, excluding the BootServiceRegistry, ClassLoaderService and StrategySelector families. This was quite straight forward, worked well and worked with Hibernate core. Steve suggested that the boot service registry and associated class loading functionality would be useful standalone as well. To see what that is like, I have now done a test extraction including the BootServiceRegistry, ClassLoaderService and StrategySelector families. It has worked quite well, but was definitely major. Part of the discussion that I had with Steve this morning, and the piece that he particularly wanted to discuss here, is how to perform the extraction and where to put it: * Is this standalone service registry its own project, separate from the hibernate-orm project. Would that make it easier to use in other projects? Or is it a hibernate-ssr module within the hibernate-orm project. * Is it called hibernate-ssr or perhaps hibernate-serviceregistry? Perhaps the later is more appropriate especially if it?s a separate project. I think the end result of the extraction I?ve done is pretty good, it does of course modify a number of classes across the hibernate-orm project (mostly just imports, though) so I?m wary that this may not be the best contribution to make as a newcomer! For reference, my WIP is here https://github.com/karlvr/hibernate-orm/compare/ssr I have done it inside the hibernate-orm project to best preserve the git metadata (e.g. source file renames). The project compiles, tests pass (except for some osgi stuff I don?t yet understand!), and it appears to work when used in a large Hibernate project of mine. The most interesting parts of migrating BootServiceRegistry et al over to the SSR is the Hibernate ORM dependencies in BootServiceRegistry - specifically Integrators. There were also Hibernate ORM specific features in StrategySelectorBuilder and ClassLoaderServiceImpl (specifically ClassLoaderHelper). I have created subclasses in hibernate-core of the implementations I moved to the SSR module, with the same class name as the original. These subclasses provide the Hibernate specific functionality. Another interesting standalone issue is the exception hierarchy. The exceptions no longer extend from HibernateException. Perhaps it would be possible to have that class in the SSR package and core to address this. I would be proud to contribute this change. I?m happy to make any changes, and I will definitely tidy up my commit messages to meet the contribution guidelines! Likewise I?m happy to throw away the work if it?s not the right approach. I had a pretty good fun morning anyway :-) Best regards, Karl From steve at hibernate.org Thu Jan 16 07:42:47 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Jan 2014 06:42:47 -0600 Subject: [hibernate-dev] Standalone service registry In-Reply-To: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> References: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> Message-ID: <52D7D3C7.4020401@hibernate.org> Hi Karl, see inline... On 01/16/2014 02:42 AM, Karl von Randow wrote: > Hi all, > > I had a conversation with Steve today on IRC about refactoring the org.hibernate.service package to make it standalone. The service registry implementation is mostly separable from Hibernate core already, and it could be useful in other applications perhaps where hibernate-core isn?t a dependency. I found myself in that exact situation, which is why I?m here. > > I have done a test extraction of the service registry classes, excluding the BootServiceRegistry, ClassLoaderService and StrategySelector families. This was quite straight forward, worked well and worked with Hibernate core. > > Steve suggested that the boot service registry and associated class loading functionality would be useful standalone as well. To see what that is like, I have now done a test extraction including the BootServiceRegistry, ClassLoaderService and StrategySelector families. It has worked quite well, but was definitely major. What do you mean it "was ... major"? Difficult? I would think that those would all peel-away pretty easily; that it would be "quite straight forward" as you said. > Part of the discussion that I had with Steve this morning, and the piece that he particularly wanted to discuss here, is how to perform the extraction and where to put it: > > * Is this standalone service registry its own project, separate from the hibernate-orm project. Would that make it easier to use in other projects? Or is it a hibernate-ssr module within the hibernate-orm project. > > * Is it called hibernate-ssr or perhaps hibernate-serviceregistry? Perhaps the later is more appropriate especially if it?s a separate project. I agree with Hardy (from IRC) that hibernate-serviceregistry is better than hibernate-ssr. For me the question really comes down to choosing between: a) https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry b) https://github.com/hibernate/hibernate-serviceregistry The implications are that in the first case hibernate-serviceregistry is a module of the hibernate-orm project. It is still a separate jar and therefore still easily consumed externally. It would be versioned along with the rest of the hibernate-orm modules. The second case makes it a little more clear that it is intended for standalone consumption. However, it does introduce the possibility of version mismatches amongst multiple consumers. If you use Hibernate ORM and Hibernate Search and use the hibernate-serviceregistry yourself, all 3 of thjese would need to agree/match on the version of hibernate-serviceregistry that is usable. That exists too when hibernate-serviceregistry is a module of Hibernate ORM, but one variable is removed. > I think the end result of the extraction I?ve done is pretty good, it does of course modify a number of classes across the hibernate-orm project (mostly just imports, though) so I?m wary that this may not be the best contribution to make as a newcomer! For reference, my WIP is here https://github.com/karlvr/hibernate-orm/compare/ssr > I have done it inside the hibernate-orm project to best preserve the git metadata (e.g. source file renames). The project compiles, tests pass (except for some osgi stuff I don?t yet understand!), and it appears to work when used in a large Hibernate project of mine. > > The most interesting parts of migrating BootServiceRegistry et al over to the SSR is the Hibernate ORM dependencies in BootServiceRegistry - specifically Integrators. There were also Hibernate ORM specific features in StrategySelectorBuilder and ClassLoaderServiceImpl (specifically ClassLoaderHelper). I have created subclasses in hibernate-core of the implementations I moved to the SSR module, with the same class name as the original. These subclasses provide the Hibernate specific functionality. Ah, I had forgotten about the direct Integrator reference on BootServiceRegistry. I'd have to think through that. What "ORM specific features" are in StrategySelectorBuilder and ClassLoaderServiceImpl? > Another interesting standalone issue is the exception hierarchy. The exceptions no longer extend from HibernateException. Perhaps it would be possible to have that class in the SSR package and core to address this. Not ideal, but not a deal-breaker either. Not convinced that *all* exceptions should be runtime-variety anyway. > I would be proud to contribute this change. I?m happy to make any changes, and I will definitely tidy up my commit messages to meet the contribution guidelines! Likewise I?m happy to throw away the work if it?s not the right approach. I had a pretty good fun morning anyway :-) Regardless of what happens, thanks for taking a look at this! From hardy at hibernate.org Thu Jan 16 10:41:05 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 16 Jan 2014 16:41:05 +0100 Subject: [hibernate-dev] Standalone service registry In-Reply-To: <52D7D3C7.4020401@hibernate.org> References: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> <52D7D3C7.4020401@hibernate.org> Message-ID: On 16 Jan 2014, at 13:42, Steve Ebersole wrote: >> Part of the discussion that I had with Steve this morning, and the piece that he particularly wanted to discuss here, is how to perform the extraction and where to put it: >> >> * Is this standalone service registry its own project, separate from the hibernate-orm project. Would that make it easier to use in other projects? Or is it a hibernate-ssr module within the hibernate-orm project. >> >> * Is it called hibernate-ssr or perhaps hibernate-serviceregistry? Perhaps the later is more appropriate especially if it?s a separate project. > > I agree with Hardy (from IRC) that hibernate-serviceregistry is better > than hibernate-ssr. For me the question really comes down to choosing > between: +1 for hibernate-serviceregistry. For me ssr is just too cryptic and and we usually use full names in modules/projects. > a) https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry > b) https://github.com/hibernate/hibernate-serviceregistry I could live with both. As Steve is saying, there are pro and cons for both. Personally, I have a slight preference for #b. >From a consumer point of view, I am not so sure which other Hibernate project would benefit from this atm. Validator has no use of it. Search maybe, but I see that a fair bit in the future. The concepts and ideas we took from ORM into the new Search ServiceManager fulfil the requirements in Search. I don?t think there is an immediate need there for a service registry artifact. Not sure about OGM!? ?Hardy From gunnar at hibernate.org Thu Jan 16 11:01:39 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 16 Jan 2014 17:01:39 +0100 Subject: [hibernate-dev] Standalone service registry In-Reply-To: References: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> <52D7D3C7.4020401@hibernate.org> Message-ID: 2014/1/16 Hardy Ferentschik > > On 16 Jan 2014, at 13:42, Steve Ebersole wrote: > > >> Part of the discussion that I had with Steve this morning, and the > piece that he particularly wanted to discuss here, is how to perform the > extraction and where to put it: > >> > >> * Is this standalone service registry its own project, separate from > the hibernate-orm project. Would that make it easier to use in other > projects? Or is it a hibernate-ssr module within the hibernate-orm project. > >> > >> * Is it called hibernate-ssr or perhaps hibernate-serviceregistry? > Perhaps the later is more appropriate especially if it?s a separate project. > > > > I agree with Hardy (from IRC) that hibernate-serviceregistry is better > > than hibernate-ssr. For me the question really comes down to choosing > > between: > > +1 for hibernate-serviceregistry. For me ssr is just too cryptic and and > we usually use full names in modules/projects. > > > a) https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry > > b) https://github.com/hibernate/hibernate-serviceregistry > > I could live with both. As Steve is saying, there are pro and cons for > both. Personally, I have a slight preference for #b. > I'd also prefer #b. A separate repo emphasizes that it is a separate project (which can be used without ORM) and it e.g. would allow to set up separate permissions, so there could be people which can commit to the registry and not to ORM and the other way around. > > >From a consumer point of view, I am not so sure which other Hibernate > project would benefit from this atm. > Validator has no use of it. Search maybe, but I see that a fair bit in the > future. The concepts and ideas we took from ORM into > the new Search ServiceManager fulfil the requirements in Search. I don?t > think there is an immediate need there for a service registry > artifact. Not sure about OGM!? > We use the registry (as it is, i.e. no modifications or copied stuff) quite a bit, but I don't think we'd gain much atm. if it was a separate artifact. We'd have to use the version pulled in by ORM all time anyways. > > ?Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From karl+hibernate at xk72.com Thu Jan 16 14:48:43 2014 From: karl+hibernate at xk72.com (Karl von Randow) Date: Fri, 17 Jan 2014 08:48:43 +1300 Subject: [hibernate-dev] Standalone service registry In-Reply-To: <52D7D3C7.4020401@hibernate.org> References: <208C3B68-0832-4FFF-B32A-C2B3C8E2602F@xk72.com> <52D7D3C7.4020401@hibernate.org> Message-ID: <27ACB843-81C0-4B26-852D-53190C25DE56@xk72.com> On 17/01/2014, at 1:42 am, Steve Ebersole wrote: > On 01/16/2014 02:42 AM, Karl von Randow wrote: >> Hi all, >> >> I had a conversation with Steve today on IRC about refactoring the org.hibernate.service package to make it standalone. The service registry implementation is mostly separable from Hibernate core already, and it could be useful in other applications perhaps where hibernate-core isn?t a dependency. I found myself in that exact situation, which is why I?m here. >> >> I have done a test extraction of the service registry classes, excluding the BootServiceRegistry, ClassLoaderService and StrategySelector families. This was quite straight forward, worked well and worked with Hibernate core. >> >> Steve suggested that the boot service registry and associated class loading functionality would be useful standalone as well. To see what that is like, I have now done a test extraction including the BootServiceRegistry, ClassLoaderService and StrategySelector families. It has worked quite well, but was definitely major. > What do you mean it "was ... major"? Difficult? I would think that those would all peel-away pretty easily; that it would be "quite straight forward" as you said. The first part, without Boot + Class + StrategySelector is easy. The only interesting dependencies are HibernateException, CoreMessageLogging and JmxService. I resolved all of those pretty easily, and migrated JmxService into the org.hibernate.service.spi package, next to its marker class Manageable. I moved two log methods from CoreMessageLogging to the new ServiceRegistryMessageLogging. The generated source is working nicely in Gradle, I presume there will be an i18n implication for this. The majorness (or is it major-ity) of the second part is related to the question below - there were quite a few places where there was ORM specific functionality woven in. So from that point of view, the standaloning may also be considered beautiful from a code structure pov. ? > >> The most interesting parts of migrating BootServiceRegistry et al over to the SSR is the Hibernate ORM dependencies in BootServiceRegistry - specifically Integrators. There were also Hibernate ORM specific features in StrategySelectorBuilder and ClassLoaderServiceImpl (specifically ClassLoaderHelper). I have created subclasses in hibernate-core of the implementations I moved to the SSR module, with the same class name as the original. These subclasses provide the Hibernate specific functionality. > > Ah, I had forgotten about the direct Integrator reference on BootServiceRegistry. I'd have to think through that. > > What "ORM specific features" are in StrategySelectorBuilder and ClassLoaderServiceImpl? I managed to separate Integrator pretty nicely I think. Hibernate core has its own BootServiceRegistry implementation that supports Integrators by subclassing the new AbstractBootServiceRegistry in SSR. I added the necessary hooks - one or two. StrategySelectorBuilder loads dialects, JTA platforms, transaction factories and multi-table bulk id strategies as part of its code. Again, this was easily separated out. I created an AbstractStrategySelectorBuilder in SSR and a subclass StrategySelectorBuilder, in its original place in core, that overrides a new addBaseline(StrategySelectorImpl) protected method and calls the addDialects etc methods extracted from the original. Pretty clean. The StrategyRegistrationProvider was a bit interesting. This is referenced by its full class name as property files in the individual modules to load strategy registration providers. As you?ll note from the commit log I only discovered this later in the migration. So I?ve added the capability to AbstractStrategySelectorBuilder to specify the StrategyRegistrationProvider sub-interface to use, modifying the original StrategyRegistrationProvider in core to extend the new one in SSR. This works pretty well. I?ve then created a DefaultStrategySelectorBuilder to live in SSR which uses the StrategyRegistrationProvider base-interface and doesn?t have any baseline strategies. ClassLoaderServiceImpl has a dependency on ClassLoaderHelper, which allows overriding of the context class loader. From the comments, this is a temporary solution, but I obviously wanted to maintain it. There was also a deprecated method fromConfigSettings(Map configValues) which is called from PersistenceXmlParser in JPA that I didn?t want to bring to SSR as it contains core specific reference (AvailableSettings.HIBERNATE_CLASSLOADER etc). I modified the original ClassLoaderServiceImpl to be a subclass of the impl in SSR and to contain those specific pieces of functionality. I also modified the BootstrapServiceRegistryBuilder so that it could choose the default ClassLoaderService implementation, and core?s builder chooses core?s one. I did all of the changes in little steps in the commit logs, so when it comes to the point of following the process it should be pretty easy to see the thinking in each step! > >> Another interesting standalone issue is the exception hierarchy. The exceptions no longer extend from HibernateException. Perhaps it would be possible to have that class in the SSR package and core to address this. > Not ideal, but not a deal-breaker either. Not convinced that *all* exceptions should be runtime-variety anyway. I only had to modify two tests, IIRC, that relied on those exceptions being HibernateException subclasses. It doesn?t seem likely that much user code relies on those exceptions as they feel much more internal to ORM. *fingers-crossed-emoji* From igor at chub.in Fri Jan 17 05:04:07 2014 From: igor at chub.in (Igor Chubin) Date: Fri, 17 Jan 2014 12:04:07 +0200 Subject: [hibernate-dev] Hibernate: How to start a single test from the Hibernate test suite? Message-ID: <20140117100407.GW30627@chub.in> Hallo, all! I suppose that my question is obvious for many, but I could not manage to find an answer on it. Please help me. Hibernate has its own test infrastructure, that can be used to test Hibernate and its various dialects. In the past, the infrastructure for a part of the Hibernate project, but later (HHH-3508) it was moved to a separate project [1]. The infrastructure is based on JUnit (the tests) and Gradle (automation of the test process) [2]. You can start all tests from the test suite using gradle: gradle hibernate-core:matrix_mysql51 In this case all tests of the hibernate-core module will be started. There are more than 4000 tests in the module. I would like to start only some of them. How do it do it? Is it possible to use the same testing infrastructure, but start single tests from the testsuite? Thank you very much for your help, [1] https://github.com/hibernate/hibernate-matrix-testing [2] https://github.com/hibernate/hibernate-orm/wiki/Hibernate-JUnit-Infastructure -- Igor Chubin From gunnar at hibernate.org Fri Jan 17 17:53:28 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Jan 2014 23:53:28 +0100 Subject: [hibernate-dev] Hibernate: How to start a single test from the Hibernate test suite? In-Reply-To: <20140117100407.GW30627@chub.in> References: <20140117100407.GW30627@chub.in> Message-ID: Hi Igor, The Gradle reference guide describes in detail the different options for specifying the tests to run via test filters and system properties in [1]. E.g. to run a single test use the "test.single" property: ./gradlew :hibernate-core:test -Dtest.single= Hth, --Gunnar [1] http://www.gradle.org/docs/current/userguide/java_plugin.html#sec:java_test 2014/1/17 Igor Chubin > > > Hallo, all! > > I suppose that my question is obvious for many, but I could not > manage to find an answer on it. > > Please help me. > > Hibernate has its own test infrastructure, that can be used to test > Hibernate and its various dialects. > > In the past, the infrastructure for a part of the Hibernate project, > but later (HHH-3508) it was moved to a separate project [1]. > > The infrastructure is based on JUnit (the tests) and Gradle > (automation of the test process) [2]. > > You can start all tests from the test suite using gradle: > > gradle hibernate-core:matrix_mysql51 > > In this case all tests of the hibernate-core module will be > started. There are more than 4000 tests in the module. > > I would like to start only some of them. > > How do it do it? Is it possible to use the same testing > infrastructure, but start single tests from the testsuite? > > Thank you very much for your help, > > > [1] https://github.com/hibernate/hibernate-matrix-testing > [2] > https://github.com/hibernate/hibernate-orm/wiki/Hibernate-JUnit-Infastructure > > -- > Igor Chubin > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From igor at chub.in Sat Jan 18 04:41:47 2014 From: igor at chub.in (Igor Chubin) Date: Sat, 18 Jan 2014 11:41:47 +0200 Subject: [hibernate-dev] Hibernate: How to start a single test from the Hibernate test suite? In-Reply-To: References: <20140117100407.GW30627@chub.in> Message-ID: <20140118094147.GY30627@chub.in> On 17. Jan 2014 11:53, Gunnar Morling wrote: > Hi Igor, > > The Gradle reference guide describes in detail the different options for > specifying the tests to run via test filters and system properties in [1]. E.g. > to run a single test use the "test.single" property: > > ? ? ./gradlew :hibernate-core:test -Dtest.single= Thank you very much, Gunnar! It works indeed. Thank you > > Hth, > > --Gunnar > > [1]?http://www.gradle.org/docs/current/userguide/java_plugin.html#sec:java_test > > > > > 2014/1/17 Igor Chubin > > > > Hallo, all! > > I suppose that my question is obvious for many, but I could not > manage to find an answer on it. > > Please help me. > > Hibernate has its own test infrastructure, that can be used to test > Hibernate and its various dialects. > > In the past, the infrastructure for a part of the Hibernate project, > but later (HHH-3508) it was moved to a separate project [1]. > > The infrastructure is based on JUnit (the tests) and Gradle > (automation of the test process) [2]. > > You can start all tests from the test suite using gradle: > > ? ? gradle hibernate-core:matrix_mysql51 > > In this case all tests of the hibernate-core module will be > started. There are more than 4000 tests in the module. > > I would like to start only some of them. > > How do it do it? Is it possible to use the same testing > infrastructure, but start single tests from the testsuite? > > Thank you very much for your help, > > > [1] https://github.com/hibernate/hibernate-matrix-testing > [2] https://github.com/hibernate/hibernate-orm/wiki/ > Hibernate-JUnit-Infastructure > > -- > Igor Chubin > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- Igor Chubin From sanne at hibernate.org Sat Jan 18 05:43:29 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 18 Jan 2014 11:43:29 +0100 Subject: [hibernate-dev] Hibernate Search being integrated in WildFly In-Reply-To: <455C9FE6-C8ED-41B3-93CB-D538AB6BDA37@hibernate.org> References: <6928FC9F-D8AB-4893-87CB-C1E47DFBB3F6@hibernate.org> <455C9FE6-C8ED-41B3-93CB-D538AB6BDA37@hibernate.org> Message-ID: On 15 January 2014 22:17, Hardy Ferentschik wrote: > >>>> I can do a release. Just wondering whether it should be a CR already? >>>> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now >>>> to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out. >>>> We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks. >>> >>> We also have the Infinispan indexmanager on the roadmap. All work was >>> done a year ago already, and the Infinispan issues which prevented me >>> to merge it at the time are fixed, so I should only need to rebase it. >>> >>> I would love to merge it, but let's set a deadline for it.. if I can't >>> make it we release without it again :-( >>> >>> Also I'm worried about HSEARCH-1260 and Guillaume's report. It would >>> be nice to get rid of those issues by applying the cleanup I've >>> suggested on that thread. >>> >>> I fundamentally agree that if we don't address these quickly, we >>> should aim at a quick Final, still let's not rush it too much as >>> WildFly doesn't stricly need a Final from us (or at least I wasn't >>> asked for one). >> >> Don?t you think that a lot of users might hold of an upgrade, because they want a final >> or at least CR release? If we want people to use 4.5 we might need to give them >> a final sooner than later. I don?t see the mentioned issues addressed in the near >> future. Guillaume for example won?t be able to look at the mass indexer until some >> time February. Is it in this case not better to do a 4.5.0.Final and then add the >> mentioned features in a 4.5.x release? > > Have we decided on a version? Sanne, you still vote for a 4.5 Beta1? Yes I vote for a release; my preference would be a Beta1 but I have no strong opinion on that, as you made some good points. My meeting is over so while I guess my answer comes a bit late, at this point today I could make the massindexer patch at least (as I guess you won't be releasing over the weekend, but if I'm wrong on that feel free to go ahead without waiting for my patch). 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 Sat Jan 18 06:12:53 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 18 Jan 2014 12:12:53 +0100 Subject: [hibernate-dev] Migrating the Migration Guides Message-ID: The new website is missing the migration guides; specifically I'm looking at Hibernate Search but since we probably want to keep a familiar structure across the various projects, I hope to get feedback from all. I'd like to move the Search migration guide from the jboss.org Wiki to ascidoc, but also it has become quite large and I think it should be split in different pages. I'd expect to see a "Migration" landing page for Search, beginning with two lines of text for general advice, to then point to: - Migrating from Hibernate Search 4.x to Hibernate Search 5.x - Minor upgrade hints across Hibernate Search 4.x versions - Migrating from Hibernate Search 3.x to Hibernate Search 4.x - Minor upgrade hints across Hibernate Search 3.x versions We probably want to suggest users to always migrate in steps of minor versions, but skipping the micro versions. For example if I'm updating an Hibernate Search 4.3.0.Final, I'd bump my dependency to 4.4.2.Final as a first step, apply some changes as suggested by the guides, run the tests, then jump again as needed. My reasoning to suggest skip the micro versions is dual-fold: - we're not supposed to break any API in that range anyway, so going through the micro hops is probably a waste of time - in case we screw up with some bug in the first release of a minor, that would make a migration harder (failing tests) and we should be correcting this with micro versions so the latest micro is what people are supposed to use to avoid this bug I guess we're all on the same page as general guidelines? I think this sounds very familiar to us as we are used to this approach but it's worthwhile to explain as occasional users might be used to different conventions or have a different understanding of versions. Could someone more familiar with the website details please structure the base layout for this? Like if we could agree quickly on the shape of the menu, I will then migrate the content for Search. N.B. I have a lot to write down urgently for the migration to Search 5 guide: I think we'll be releasing a first preview next week and these docs should be in place. If that doesn't work out I can of course write it in the existing wiki. Sanne From hardy at hibernate.org Sat Jan 18 07:17:09 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Sat, 18 Jan 2014 13:17:09 +0100 Subject: [hibernate-dev] Migrating the Migration Guides In-Reply-To: References: Message-ID: On 18 Jan 2014, at 12:12, Sanne Grinovero wrote: > The new website is missing the migration guides; specifically I'm > looking at Hibernate Search but since we probably want to keep a > familiar structure across the various projects, I hope to get feedback > from all. I agree, we probably should add the migration guides to the site. However, I am not a big fan of the existing ones and just migrating them. I think they are badly structured. I would consider leaving the existing guides where they are (at least for now) and just start with a 4 to 5 migration. You can always add a link to the old guide. Another benefit is that you don?t waste time migration the guides and can focus directly what you want to do. > I'd like to move the Search migration guide from the jboss.org Wiki to > ascidoc, but also it has become quite large and I think it should be > split in different pages. If you want to migrate, it should for sure be split. As I mentioned above I would not bother for now with a migration, or it at all only migrate the latest changes. > - Migrating from Hibernate Search 3.x to Hibernate Search 4.x > - Minor upgrade hints across Hibernate Search 3.x versions Do we still need that? > We probably want to suggest users to always migrate in steps of minor > versions, but skipping the micro versions. > For example if I'm updating an Hibernate Search 4.3.0.Final, I'd bump > my dependency to 4.4.2.Final as a first step, apply some changes as > suggested by the guides, run the tests, then jump again as needed. Probably not what I would do. If I want go to the version I want to use first. Only if I would face major problems I would back step. I don?t think that many people would do this incremental approach. Obviously that?s my opinion, but at least it shows that there are different approaches to this. > I guess we're all on the same page as general guidelines? I think this > sounds very familiar to us as we are used to this approach I exlude myself here. > Could someone more familiar with the website details please structure > the base layout for this? It should be straight forward. Create a directory called ?migration? and and a index.adoc. Edit site.yml and add a new intern link. You can start with doing this just for Search or apply this already to all projects. index.adoc can be the general page you are talking about. Just place additional migration guides into the same directory. I don?t think there is more to it. If in the end there is something which we want to add to each project we can extract a partial at a alter stage. ?Hardy From sanne at hibernate.org Sat Jan 18 17:32:00 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 18 Jan 2014 23:32:00 +0100 Subject: [hibernate-dev] Migrating the Migration Guides In-Reply-To: References: Message-ID: On 18 January 2014 13:17, Hardy Ferentschik wrote: > > On 18 Jan 2014, at 12:12, Sanne Grinovero wrote: > >> The new website is missing the migration guides; specifically I'm >> looking at Hibernate Search but since we probably want to keep a >> familiar structure across the various projects, I hope to get feedback >> from all. > > I agree, we probably should add the migration guides to the site. > However, I am not a big fan of the existing ones and just migrating them. > I think they are badly structured. I would consider leaving the existing guides > where they are (at least for now) and just start with a 4 to 5 migration. You > can always add a link to the old guide. > > Another benefit is that you don?t waste time migration the guides and can focus > directly what you want to do. Ok good idea I'll focus only on the 4 to 5 aspect for now. Still, at some point I'd like to migrate them all. > >> I'd like to move the Search migration guide from the jboss.org Wiki to >> ascidoc, but also it has become quite large and I think it should be >> split in different pages. > > If you want to migrate, it should for sure be split. As I mentioned above I > would not bother for now with a migration, or it at all only migrate the latest changes. > >> - Migrating from Hibernate Search 3.x to Hibernate Search 4.x >> - Minor upgrade hints across Hibernate Search 3.x versions > > Do we still need that? No need to migrate them now but I see no value in deleting those guides either. There definitely are many deployments out there using it, at least just counting my own creations :-) >> We probably want to suggest users to always migrate in steps of minor >> versions, but skipping the micro versions. >> For example if I'm updating an Hibernate Search 4.3.0.Final, I'd bump >> my dependency to 4.4.2.Final as a first step, apply some changes as >> suggested by the guides, run the tests, then jump again as needed. > > Probably not what I would do. If I want go to the version I want to use first. > Only if I would face major problems I would back step. I don?t think that many > people would do this incremental approach. Obviously that?s my opinion, > but at least it shows that there are different approaches to this. You're probably right on what I'd also do as primary strategy, but as you also suggest you would fallback to step by step in case of trouble, and at that point it's handy to have docs. >> I guess we're all on the same page as general guidelines? I think this >> sounds very familiar to us as we are used to this approach > > I exlude myself here. Not sure I follow, as I'm confident you and myself are using the same approach to major.minor.micro: I guess my own explanation was unclear. What I meant to highlight is that the structure of our migration guides should be organized from minor to minor, and in a broader category major to major, but that the granularity of micro releases is of less importance. So that while major migrations could have dedicated pages, and each minor is probably a section, the strict division between micro releases is probably of low interest. I hope we're all on the same page on that so that we can give some consistent guidelines? >> Could someone more familiar with the website details please structure >> the base layout for this? > > It should be straight forward. Create a directory called ?migration? and and a index.adoc. > Edit site.yml and add a new intern link. You can start with doing this just for Search or apply > this already to all projects. index.adoc can be the general page you are talking about. Just place > additional migration guides into the same directory. I don?t think there is more to it. If in the end there > is something which we want to add to each project we can extract a partial at a alter stage. thanks! --Sanne > > ?Hardy > > From gunnar at hibernate.org Mon Jan 20 06:23:05 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 20 Jan 2014 12:23:05 +0100 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM Message-ID: Hi, While reviewing the PR for batch operations in OGM [1], I took some time to better understand OGM's approaches for id generation. Now I'm wondering about how GenerationType.IDENTITY is implemented. The corresponding generator (OgmIdentityGenerator) just delegates to a table-based strategy, so an id is always pre-allocated and then passed into the dialect when creating a tuple. I think it would be nice to have proper support for server-generated ids, in particular since some stores return the inserted id directly from the insert operation, i.e. without requiring another read. For the time being, as the current implementation doesn't really adhere to the semantics of GenerationType.IDENTITY, should we raise an error when using it instead of silently using another strategy? Thoughts? --Gunnar [1] https://hibernate.atlassian.net/browse/OGM-175 From emmanuel at hibernate.org Mon Jan 20 10:18:58 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 20 Jan 2014 16:18:58 +0100 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM In-Reply-To: References: Message-ID: <20140120151858.GD71332@hibernate.org> The problem is that in JPA, IDENTITY returns a long, not a UUID. On Mon 2014-01-20 12:23, Gunnar Morling wrote: > Hi, > > While reviewing the PR for batch operations in OGM [1], I took some time to > better understand OGM's approaches for id generation. > > Now I'm wondering about how GenerationType.IDENTITY is implemented. The > corresponding generator (OgmIdentityGenerator) just delegates to a > table-based strategy, so an id is always pre-allocated and then passed into > the dialect when creating a tuple. > > I think it would be nice to have proper support for server-generated ids, > in particular since some stores return the inserted id directly from the > insert operation, i.e. without requiring another read. > > For the time being, as the current implementation doesn't really adhere to > the semantics of GenerationType.IDENTITY, should we raise an error when > using it instead of silently using another strategy? > > Thoughts? > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/OGM-175 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Jan 20 10:40:34 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 20 Jan 2014 16:40:34 +0100 Subject: [hibernate-dev] Fwd: [wildfly-dev] Hibernate Bug (tables starting with "and")... In-Reply-To: <1612511220.3043439.1390232117726.JavaMail.root@redhat.com> References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com> <238591768.3028872.1390230534795.JavaMail.root@redhat.com> <1612511220.3043439.1390232117726.JavaMail.root@redhat.com> Message-ID: Hi, Jess Sightler had sent the original mail below to wildfly-dev, but it seems more suited here. --Gunnar ---------- Forwarded message ---------- From: Jess Sightler Date: 2014/1/20 Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... To: Toma? Cerar Cc: wildfly-dev at lists.jboss.org I agree, but I am not on hibernate-dev, unfortunately, and this seems like an issue that could affect a lot of people if it goes into the Wildfly final release. I believe that you have misunderstood the issue here. The issue is not putting quotes around it (although I guess that might work around the bug). The issue is that if you have a table starting with "and" (eg, "androidvariant"), then this code will think it starts with " and" (note the space). It will then proceed to rip off the first 4 characters, turning your table name into "oidvariant". Note how the code also does not do what the comment describing it says it will do. Ie, it tries to remove " and" and "and ", but only checks for "and" (no spaces) before doing the trimming. ----- Original Message ----- > From: "Toma? Cerar" > To: "Jess Sightler" > Cc: wildfly-dev at lists.jboss.org > Sent: Monday, January 20, 2014 10:28:40 AM > Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... > > Question would be more suitable for hibernate-dev mailing list. > but in any case i am pretty sure your fix is wrong, given that you can > achieve what you want different way. > > see > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor > more details. > or even > http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names > > -- > tomaz > > > On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler wrote: > > > Is there any chance of getting a fix for this into the 8.0.0.Final release? > > https://github.com/hibernate/hibernate-orm/pull/658 > > > > It seems to break a lot of generated queries on tables starting with "and". > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From gunnar at hibernate.org Mon Jan 20 11:42:24 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 20 Jan 2014 17:42:24 +0100 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM In-Reply-To: <20140120151858.GD71332@hibernate.org> References: <20140120151858.GD71332@hibernate.org> Message-ID: Ah, is that specified somewhere? I couldn't find anything in the spec from a quick look. 2014/1/20 Emmanuel Bernard > The problem is that in JPA, IDENTITY returns a long, not a UUID. > > On Mon 2014-01-20 12:23, Gunnar Morling wrote: > > Hi, > > > > While reviewing the PR for batch operations in OGM [1], I took some time > to > > better understand OGM's approaches for id generation. > > > > Now I'm wondering about how GenerationType.IDENTITY is implemented. The > > corresponding generator (OgmIdentityGenerator) just delegates to a > > table-based strategy, so an id is always pre-allocated and then passed > into > > the dialect when creating a tuple. > > > > I think it would be nice to have proper support for server-generated ids, > > in particular since some stores return the inserted id directly from the > > insert operation, i.e. without requiring another read. > > > > For the time being, as the current implementation doesn't really adhere > to > > the semantics of GenerationType.IDENTITY, should we raise an error when > > using it instead of silently using another strategy? > > > > Thoughts? > > > > --Gunnar > > > > [1] https://hibernate.atlassian.net/browse/OGM-175 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 20 13:37:53 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 20 Jan 2014 12:37:53 -0600 Subject: [hibernate-dev] Fwd: [wildfly-dev] Hibernate Bug (tables starting with "and")... In-Reply-To: References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com> <238591768.3028872.1390230534795.JavaMail.root@redhat.com> <1612511220.3043439.1390232117726.JavaMail.root@redhat.com> Message-ID: <52DD6D01.5080801@hibernate.org> Yep, I'll make sure this gets into Hibernate ORM 4.3.1. Up to WildFly to decide if they want 4.3.1 On 01/20/2014 09:40 AM, Gunnar Morling wrote: > Hi, > > Jess Sightler had sent the original mail below to wildfly-dev, but it seems > more suited here. > > --Gunnar > > ---------- Forwarded message ---------- > From: Jess Sightler > Date: 2014/1/20 > Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... > To: Toma? Cerar > Cc: wildfly-dev at lists.jboss.org > > > I agree, but I am not on hibernate-dev, unfortunately, and this seems like > an issue that could affect a lot of people if it goes into the Wildfly > final release. > > I believe that you have misunderstood the issue here. The issue is not > putting quotes around it (although I guess that might work around the bug). > > The issue is that if you have a table starting with "and" (eg, > "androidvariant"), then this code will think it starts with " and" (note > the space). It will then proceed to rip off the first 4 characters, turning > your table name into "oidvariant". > > Note how the code also does not do what the comment describing it says it > will do. Ie, it tries to remove " and" and "and ", but only checks for > "and" (no spaces) before doing the trimming. > > ----- Original Message ----- >> From: "Toma? Cerar" >> To: "Jess Sightler" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Monday, January 20, 2014 10:28:40 AM >> Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... >> >> Question would be more suitable for hibernate-dev mailing list. >> but in any case i am pretty sure your fix is wrong, given that you can >> achieve what you want different way. >> >> see >> > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor >> more details. >> or even >> > http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names >> -- >> tomaz >> >> >> On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler > wrote: >>> Is there any chance of getting a fix for this into the 8.0.0.Final > release? >>> https://github.com/hibernate/hibernate-orm/pull/658 >>> >>> It seems to break a lot of generated queries on tables starting with > "and". >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From jsightle at redhat.com Mon Jan 20 14:37:16 2014 From: jsightle at redhat.com (Jess Sightler) Date: Mon, 20 Jan 2014 14:37:16 -0500 (EST) Subject: [hibernate-dev] Fwd: [wildfly-dev] Hibernate Bug (tables starting with "and")... In-Reply-To: <52DD6D01.5080801@hibernate.org> References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com> <238591768.3028872.1390230534795.JavaMail.root@redhat.com> <1612511220.3043439.1390232117726.JavaMail.root@redhat.com> <52DD6D01.5080801@hibernate.org> Message-ID: <1716840197.3192954.1390246636944.JavaMail.root@redhat.com> Thanks Steve! ----- Original Message ----- > From: "Steve Ebersole" > To: "Gunnar Morling" , hibernate-dev at lists.jboss.org > Cc: jsightle at redhat.com > Sent: Monday, January 20, 2014 1:37:53 PM > Subject: Re: [hibernate-dev] Fwd: [wildfly-dev] Hibernate Bug (tables starting with "and")... > > Yep, I'll make sure this gets into Hibernate ORM 4.3.1. Up to WildFly to > decide if they want 4.3.1 > > > On 01/20/2014 09:40 AM, Gunnar Morling wrote: > > Hi, > > > > Jess Sightler had sent the original mail below to wildfly-dev, but it seems > > more suited here. > > > > --Gunnar > > > > ---------- Forwarded message ---------- > > From: Jess Sightler > > Date: 2014/1/20 > > Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... > > To: Toma? Cerar > > Cc: wildfly-dev at lists.jboss.org > > > > > > I agree, but I am not on hibernate-dev, unfortunately, and this seems like > > an issue that could affect a lot of people if it goes into the Wildfly > > final release. > > > > I believe that you have misunderstood the issue here. The issue is not > > putting quotes around it (although I guess that might work around the bug). > > > > The issue is that if you have a table starting with "and" (eg, > > "androidvariant"), then this code will think it starts with " and" (note > > the space). It will then proceed to rip off the first 4 characters, turning > > your table name into "oidvariant". > > > > Note how the code also does not do what the comment describing it says it > > will do. Ie, it tries to remove " and" and "and ", but only checks for > > "and" (no spaces) before doing the trimming. > > > > ----- Original Message ----- > >> From: "Toma? Cerar" > >> To: "Jess Sightler" > >> Cc: wildfly-dev at lists.jboss.org > >> Sent: Monday, January 20, 2014 10:28:40 AM > >> Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")... > >> > >> Question would be more suitable for hibernate-dev mailing list. > >> but in any case i am pretty sure your fix is wrong, given that you can > >> achieve what you want different way. > >> > >> see > >> > > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor > >> more details. > >> or even > >> > > http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names > >> -- > >> tomaz > >> > >> > >> On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler > > wrote: > >>> Is there any chance of getting a fix for this into the 8.0.0.Final > > release? > >>> https://github.com/hibernate/hibernate-orm/pull/658 > >>> > >>> It seems to break a lot of generated queries on tables starting with > > "and". > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-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 Jan 21 07:55:09 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 21 Jan 2014 12:55:09 +0000 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM In-Reply-To: References: <20140120151858.GD71332@hibernate.org> Message-ID: I don't know if that's explicitly defined in the spec, but even if it wasn't I wouldn't be happy as a user to see an exception for such a commonly used feature. Clearly when such an ID is requested we need to invoke the server out of the batching / transaction context, which might be a suboptimal strategy but exactly what the user is asking for:theyr choice of they want to tradeoff simplicity for performance. Also to keep in mind for the Infinispan case the current approach is very slow but now that we've upgraded to latest wildfly there's a new feature could use to optimise for this: COUNTER protocol in JGroups combined with FORK channels. Sanne On 20 Jan 2014 16:42, "Gunnar Morling" wrote: > Ah, is that specified somewhere? I couldn't find anything in the spec from > a quick look. > > > 2014/1/20 Emmanuel Bernard > > > The problem is that in JPA, IDENTITY returns a long, not a UUID. > > > > On Mon 2014-01-20 12:23, Gunnar Morling wrote: > > > Hi, > > > > > > While reviewing the PR for batch operations in OGM [1], I took some > time > > to > > > better understand OGM's approaches for id generation. > > > > > > Now I'm wondering about how GenerationType.IDENTITY is implemented. The > > > corresponding generator (OgmIdentityGenerator) just delegates to a > > > table-based strategy, so an id is always pre-allocated and then passed > > into > > > the dialect when creating a tuple. > > > > > > I think it would be nice to have proper support for server-generated > ids, > > > in particular since some stores return the inserted id directly from > the > > > insert operation, i.e. without requiring another read. > > > > > > For the time being, as the current implementation doesn't really adhere > > to > > > the semantics of GenerationType.IDENTITY, should we raise an error when > > > using it instead of silently using another strategy? > > > > > > Thoughts? > > > > > > --Gunnar > > > > > > [1] https://hibernate.atlassian.net/browse/OGM-175 > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev 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 Jan 21 08:25:01 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 21 Jan 2014 14:25:01 +0100 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM In-Reply-To: References: <20140120151858.GD71332@hibernate.org> Message-ID: 2014/1/21 Sanne Grinovero > I don't know if that's explicitly defined in the spec, but even if it > wasn't I wouldn't be happy as a user to see an exception for such a > commonly used feature. > So you prefer to silently use another strategy than the one configured instead of reporting the issue? Wouldn't rather a user work with AUTO if she wanted the engine to choose a strategy? Do you know how ORM handles the case of using IDENTITY on stores which don't support it? > Clearly when such an ID is requested we need to invoke the server out of > the batching / transaction context, which might be a suboptimal strategy > but exactly what the user is asking for:theyr choice of they want to > tradeoff simplicity for performance. > I'm not quite following. Using TABLE behavior instead of IDENTITY doesn't seem like doing what the user has asked for? > Also to keep in mind for the Infinispan case the current approach is > very slow but now that we've upgraded to latest wildfly there's a new > feature could use to optimise for this: COUNTER protocol in JGroups > combined with FORK channels. > That's interesting, do you have a pointer with more information on that? > Sanne > On 20 Jan 2014 16:42, "Gunnar Morling" wrote: > >> Ah, is that specified somewhere? I couldn't find anything in the spec from >> a quick look. >> >> >> 2014/1/20 Emmanuel Bernard >> >> > The problem is that in JPA, IDENTITY returns a long, not a UUID. >> > >> > On Mon 2014-01-20 12:23, Gunnar Morling wrote: >> > > Hi, >> > > >> > > While reviewing the PR for batch operations in OGM [1], I took some >> time >> > to >> > > better understand OGM's approaches for id generation. >> > > >> > > Now I'm wondering about how GenerationType.IDENTITY is implemented. >> The >> > > corresponding generator (OgmIdentityGenerator) just delegates to a >> > > table-based strategy, so an id is always pre-allocated and then passed >> > into >> > > the dialect when creating a tuple. >> > > >> > > I think it would be nice to have proper support for server-generated >> ids, >> > > in particular since some stores return the inserted id directly from >> the >> > > insert operation, i.e. without requiring another read. >> > > >> > > For the time being, as the current implementation doesn't really >> adhere >> > to >> > > the semantics of GenerationType.IDENTITY, should we raise an error >> when >> > > using it instead of silently using another strategy? >> > > >> > > Thoughts? >> > > >> > > --Gunnar >> > > >> > > [1] https://hibernate.atlassian.net/browse/OGM-175 >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev 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 manderse at redhat.com Tue Jan 21 08:36:44 2014 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 21 Jan 2014 14:36:44 +0100 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: <52D68A6E.8040604@hibernate.org> References: <52D68A6E.8040604@hibernate.org> Message-ID: > We have been having a lot of trouble lately with relying on jbott to > record the team meetings on irc. A few times jbott has not been in > the > room. A few times it refuses to start/end meetings. > > Max, is there anything to be done to make jbott more stable? jbott had been running for months without problems (at least none known to me) - then there was a network disconnect at neuchatel office which meant it was off for a bit and then came back on. I know that it has gotten slower at ending meetings, i.e. it now takes some minutes for it to upload instead of seconds as in past. I can look into speeding that up if that is the problem you are seeing. Is that what you are seeing ? /max From manderse at redhat.com Tue Jan 21 08:45:08 2014 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 21 Jan 2014 14:45:08 +0100 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: References: <52D68A6E.8040604@hibernate.org> Message-ID: so I found whats wrong - the jbott been running for 4 years and one of the things it does when ending meetings is regenerating indexes ....that was fast the first couple of years....now its turned "slow" because it happens sequentially ;) I'll see what I can do to fix that dumb logic. /max On 21 Jan 2014, at 14:36, Max Rydahl Andersen wrote: >> We have been having a lot of trouble lately with relying on jbott to >> record the team meetings on irc. A few times jbott has not been in >> the >> room. A few times it refuses to start/end meetings. >> >> Max, is there anything to be done to make jbott more stable? > > jbott had been running for months without problems (at least none > known to me) - then there was > a network disconnect at neuchatel office which meant it was off for a > bit and then came back on. > > I know that it has gotten slower at ending meetings, i.e. it now takes > some minutes > for it to upload instead of seconds as in past. I can look into > speeding that up if that is the > problem you are seeing. > > Is that what you are seeing ? > > /max From sanne at hibernate.org Tue Jan 21 08:51:58 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 21 Jan 2014 13:51:58 +0000 Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM In-Reply-To: References: <20140120151858.GD71332@hibernate.org> Message-ID: On 21 January 2014 13:25, Gunnar Morling wrote: > 2014/1/21 Sanne Grinovero >> >> I don't know if that's explicitly defined in the spec, but even if it >> wasn't I wouldn't be happy as a user to see an exception for such a commonly >> used feature. > > So you prefer to silently use another strategy than the one configured > instead of reporting the issue? Wouldn't rather a user work with AUTO if she > wanted the engine to choose a strategy? Confused. I'm stating the opposite: if the user is explicitly demanding IDENTITY strategy, we should not override that. Otherwise he/she should definitely use AUTO. > > Do you know how ORM handles the case of using IDENTITY on stores which don't > support it? Sure, you get an exception. You don't have to implement it from a spec perspective, I'm just saying it's nice to have and makes a lot of sense for practical needs to support Longs rather than UUIDs. >> >> Clearly when such an ID is requested we need to invoke the server out of >> the batching / transaction context, which might be a suboptimal strategy but >> exactly what the user is asking for:theyr choice of they want to tradeoff >> simplicity for performance. > > I'm not quite following. Using TABLE behavior instead of IDENTITY doesn't > seem like doing what the user has asked for? Agree, and confused too. I didn't know we where actually using TABLE, although in our "databases" the difference might be unclear in some cases? >> >> Also to keep in mind for the Infinispan case the current approach is very >> slow but now that we've upgraded to latest wildfly there's a new feature >> could use to optimise for this: COUNTER protocol in JGroups combined with >> FORK channels. > > That's interesting, do you have a pointer with more information on that? - http://belaban.blogspot.co.uk/2013/08/how-to-hijack-jgroups-channel-inside.html - https://raw.github.com/belaban/JGroups/master/doc/design/FORK.txt The docs specifically make the COUNTER example, as that's what I had in mind when we designed the new protocols ;-) We created this _because of_ the OGM needs. Sanne > >> >> Sanne >> >> On 20 Jan 2014 16:42, "Gunnar Morling" wrote: >>> >>> Ah, is that specified somewhere? I couldn't find anything in the spec >>> from >>> a quick look. >>> >>> >>> 2014/1/20 Emmanuel Bernard >>> >>> > The problem is that in JPA, IDENTITY returns a long, not a UUID. >>> > >>> > On Mon 2014-01-20 12:23, Gunnar Morling wrote: >>> > > Hi, >>> > > >>> > > While reviewing the PR for batch operations in OGM [1], I took some >>> > > time >>> > to >>> > > better understand OGM's approaches for id generation. >>> > > >>> > > Now I'm wondering about how GenerationType.IDENTITY is implemented. >>> > > The >>> > > corresponding generator (OgmIdentityGenerator) just delegates to a >>> > > table-based strategy, so an id is always pre-allocated and then >>> > > passed >>> > into >>> > > the dialect when creating a tuple. >>> > > >>> > > I think it would be nice to have proper support for server-generated >>> > > ids, >>> > > in particular since some stores return the inserted id directly from >>> > > the >>> > > insert operation, i.e. without requiring another read. >>> > > >>> > > For the time being, as the current implementation doesn't really >>> > > adhere >>> > to >>> > > the semantics of GenerationType.IDENTITY, should we raise an error >>> > > when >>> > > using it instead of silently using another strategy? >>> > > >>> > > Thoughts? >>> > > >>> > > --Gunnar >>> > > >>> > > [1] https://hibernate.atlassian.net/browse/OGM-175 >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev 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 Tue Jan 21 10:11:08 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 21 Jan 2014 09:11:08 -0600 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: References: <52D68A6E.8040604@hibernate.org> Message-ID: <52DE8E0C.4090106@hibernate.org> The issue with slowness of ending the meeting was annoying yes. Thanks for finding that. The other issue is that jbott is sometimes just not there. It drops off quite a bit. To give you a flavor, here is its drops from just yesterday: 01:44 *** jbott has quit IRC (Ping timeout: 272 seconds) 14:03 *** jbott has quit IRC (Ping timeout: 272 seconds) 22:19 *** jbott has quit IRC (Ping timeout: 252 seconds) 23:23 *** jbott has quit IRC (Ping timeout: 265 seconds) There has been at least one occasion when we had a meeting and jbott was simply not in the room the entire time. On Tue 21 Jan 2014 07:45:08 AM CST, Max Rydahl Andersen wrote: > > so I found whats wrong - the jbott been running for 4 years and one of > the things it does when ending meetings is regenerating indexes > ....that was fast the first couple of years....now its turned "slow" > because it happens sequentially ;) > > I'll see what I can do to fix that dumb logic. > > /max > > > On 21 Jan 2014, at 14:36, Max Rydahl Andersen wrote: > >>> We have been having a lot of trouble lately with relying on jbott to >>> record the team meetings on irc. A few times jbott has not been in the >>> room. A few times it refuses to start/end meetings. >>> >>> Max, is there anything to be done to make jbott more stable? >> >> jbott had been running for months without problems (at least none >> known to me) - then there was >> a network disconnect at neuchatel office which meant it was off for a >> bit and then came back on. >> >> I know that it has gotten slower at ending meetings, i.e. it now >> takes some minutes >> for it to upload instead of seconds as in past. I can look into >> speeding that up if that is the >> problem you are seeing. >> >> Is that what you are seeing ? >> >> /max From steve at hibernate.org Tue Jan 21 15:34:58 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 21 Jan 2014 14:34:58 -0600 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: <52DE8E0C.4090106@hibernate.org> References: <52D68A6E.8040604@hibernate.org> <52DE8E0C.4090106@hibernate.org> Message-ID: <52DED9F2.3030308@hibernate.org> So for today's meeting, jbott has still not ended the meeting. And that was 4 hours ago. At least it has not responded with the URLs. Is it still going? On Tue 21 Jan 2014 09:11:08 AM CST, Steve Ebersole wrote: > The issue with slowness of ending the meeting was annoying yes. > Thanks for finding that. > > The other issue is that jbott is sometimes just not there. It drops > off quite a bit. To give you a flavor, here is its drops from just > yesterday: > > 01:44 *** jbott has quit > IRC (Ping timeout: 272 seconds) > 14:03 *** jbott has quit > IRC (Ping timeout: 272 seconds) > 22:19 *** jbott has quit > IRC (Ping timeout: 252 seconds) > 23:23 *** jbott has quit > IRC (Ping timeout: 265 seconds) > > There has been at least one occasion when we had a meeting and jbott > was simply not in the room the entire time. > > > On Tue 21 Jan 2014 07:45:08 AM CST, Max Rydahl Andersen wrote: >> >> so I found whats wrong - the jbott been running for 4 years and one of >> the things it does when ending meetings is regenerating indexes >> ....that was fast the first couple of years....now its turned "slow" >> because it happens sequentially ;) >> >> I'll see what I can do to fix that dumb logic. >> >> /max >> >> >> On 21 Jan 2014, at 14:36, Max Rydahl Andersen wrote: >> >>>> We have been having a lot of trouble lately with relying on jbott to >>>> record the team meetings on irc. A few times jbott has not been in >>>> the >>>> room. A few times it refuses to start/end meetings. >>>> >>>> Max, is there anything to be done to make jbott more stable? >>> >>> jbott had been running for months without problems (at least none >>> known to me) - then there was >>> a network disconnect at neuchatel office which meant it was off for a >>> bit and then came back on. >>> >>> I know that it has gotten slower at ending meetings, i.e. it now >>> takes some minutes >>> for it to upload instead of seconds as in past. I can look into >>> speeding that up if that is the >>> problem you are seeing. >>> >>> Is that what you are seeing ? >>> >>> /max From manderse at redhat.com Tue Jan 21 18:19:53 2014 From: manderse at redhat.com (Max Andersen) Date: Tue, 21 Jan 2014 18:19:53 -0500 (EST) Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: <52DED9F2.3030308@hibernate.org> References: <52D68A6E.8040604@hibernate.org> <52DE8E0C.4090106@hibernate.org> <52DED9F2.3030308@hibernate.org> Message-ID: <072ADA7A-050D-4A66-9296-4699E4308364@redhat.com> The meetings are uploaded - it's just that jirabot looses the connection while that is happening so it doesn't get to tell it. http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-01-21-16.04.html I got a fix cooked up i think should make things better. I'll try get it in place tomorrow after a bit more testing. /max (sent from my phone) > On 21/01/2014, at 21.35, Steve Ebersole wrote: > > So for today's meeting, jbott has still not ended the meeting. And that was 4 hours ago. At least it has not responded with the URLs. Is it still going? > > >> On Tue 21 Jan 2014 09:11:08 AM CST, Steve Ebersole wrote: >> The issue with slowness of ending the meeting was annoying yes. >> Thanks for finding that. >> >> The other issue is that jbott is sometimes just not there. It drops >> off quite a bit. To give you a flavor, here is its drops from just >> yesterday: >> >> 01:44 *** jbott has quit >> IRC (Ping timeout: 272 seconds) >> 14:03 *** jbott has quit >> IRC (Ping timeout: 272 seconds) >> 22:19 *** jbott has quit >> IRC (Ping timeout: 252 seconds) >> 23:23 *** jbott has quit >> IRC (Ping timeout: 265 seconds) >> >> There has been at least one occasion when we had a meeting and jbott >> was simply not in the room the entire time. >> >> >>> On Tue 21 Jan 2014 07:45:08 AM CST, Max Rydahl Andersen wrote: >>> >>> so I found whats wrong - the jbott been running for 4 years and one of >>> the things it does when ending meetings is regenerating indexes >>> ....that was fast the first couple of years....now its turned "slow" >>> because it happens sequentially ;) >>> >>> I'll see what I can do to fix that dumb logic. >>> >>> /max >>> >>> >>> On 21 Jan 2014, at 14:36, Max Rydahl Andersen wrote: >>> >>>>> We have been having a lot of trouble lately with relying on jbott to >>>>> record the team meetings on irc. A few times jbott has not been in >>>>> the >>>>> room. A few times it refuses to start/end meetings. >>>>> >>>>> Max, is there anything to be done to make jbott more stable? >>>> >>>> jbott had been running for months without problems (at least none >>>> known to me) - then there was >>>> a network disconnect at neuchatel office which meant it was off for a >>>> bit and then came back on. >>>> >>>> I know that it has gotten slower at ending meetings, i.e. it now >>>> takes some minutes >>>> for it to upload instead of seconds as in past. I can look into >>>> speeding that up if that is the >>>> problem you are seeing. >>>> >>>> Is that what you are seeing ? >>>> >>>> /max From levantsinadze at gmail.com Tue Jan 21 18:54:59 2014 From: levantsinadze at gmail.com (Levan Tsinadze) Date: Wed, 22 Jan 2014 03:54:59 +0400 Subject: [hibernate-dev] Prepared statement for EAGER entity relations returning cursor not closed Message-ID: Hello everybody I found that after migrating from 4.2.8.Final to 4.3.0.Final, if I have several @OneToMany EAGER entity relations and select at least 500 rows I get ORA-01000: maximum open cursors exceeded JDBC exception for Oracle database (ojdbc 12.1.0.1) I think problem is in org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad method which calls (line 156, column 106) org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(ResultSet resultSet, Statement statement) method and this last method closes only passed ResultSet, not Statement. I also found that in 4.2.7.SP1 in such case is called org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(Statement statement) which closes as ResultSet as passed Statement. Sincerely, Levan Tsinadze From sanne at hibernate.org Wed Jan 22 03:32:51 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 22 Jan 2014 08:32:51 +0000 Subject: [hibernate-dev] New parser bugs reported: HQLPARSER vs HHH ? Message-ID: A forum user had some trouble with the current HQL parser: https://forum.hibernate.org/viewtopic.php?f=1&t=1030515 And since I've been slow to react, he went ahead and created a JIRA; I think he's right about this, still then - as you can see from his latest post - he felt unsure on where to open it, and it became HQLPARSER-35. Since this is about the current parser, he's probably in the wrong place, and there is a risk that the ORM team won't notice timely? but I don't think I can blame him as it's probably confusing. My first impulse was to jump on JIRA and see if I could enable some big fat warning on HQLPARSER to explain the difference, but actually maybe it's better if the ORM team could start looking at new issues in there as _actual_ issues? I'm thinking that while HQLPARSER matures, it should also incorporate fixes/tests happening on the mainline parser: if there was a single place to track defects of both I could "catch up" on ORM improvements when working on it. So... should I move HQLPARSER-35 to HHH, or shall we leave it there ? Maybe better to duplicate the issues? I'm voting for duplication, as they require either a fix or at least a test applied to both projects, and we probably want to keep lifecycle independent for a while longer. Sanne From manderse at redhat.com Wed Jan 22 06:09:56 2014 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 22 Jan 2014 12:09:56 +0100 Subject: [hibernate-dev] irc team meetings and jbott In-Reply-To: <52DE8E0C.4090106@hibernate.org> References: <52D68A6E.8040604@hibernate.org> <52DE8E0C.4090106@hibernate.org> Message-ID: On 21 Jan 2014, at 16:11, Steve Ebersole wrote: > The issue with slowness of ending the meeting was annoying yes. > Thanks for finding that. > > The other issue is that jbott is sometimes just not there. It drops > off quite a bit. To give you a flavor, here is its drops from just > yesterday: > > 01:44 *** jbott has quit > IRC (Ping timeout: 272 seconds) > 14:03 *** jbott has quit > IRC (Ping timeout: 272 seconds) > 22:19 *** jbott has quit > IRC (Ping timeout: 252 seconds) > 23:23 *** jbott has quit > IRC (Ping timeout: 265 seconds) So yeah, these drops was caused by jbott taking ages to sync - while it was syncing free node was pinging if it was alive and apparently subybot is single threaded so it lost the connection while it was spending 3-10 minutes on syncing. I've fixed that now by having rsync ignore 2011,2012 and 2013 folders. Thus assuming I'm right and done the fixes properly these dropouts should not happen anymore and the sync/response for end meeting and start meeting should be much faster and more consistent. Let me know if you observe it differently. > There has been at least one occasion when we had a meeting and jbott > was simply not in the room the entire time. Yeah, if that happens something is most likely wrong with its network connection - but I can see the bot have been running for ~5 months straight now and last time I restarted it was because of network change in neuchatel. Thus if you see it missing let me know - something must have occurred that the startup script is not considering but for now I haven't seen that. I've sent mail to core about the changes to let others know. /max > > On Tue 21 Jan 2014 07:45:08 AM CST, Max Rydahl Andersen wrote: >> >> so I found whats wrong - the jbott been running for 4 years and one >> of >> the things it does when ending meetings is regenerating indexes >> ....that was fast the first couple of years....now its turned "slow" >> because it happens sequentially ;) >> >> I'll see what I can do to fix that dumb logic. >> >> /max >> >> >> On 21 Jan 2014, at 14:36, Max Rydahl Andersen wrote: >> >>>> We have been having a lot of trouble lately with relying on jbott >>>> to >>>> record the team meetings on irc. A few times jbott has not been in >>>> the >>>> room. A few times it refuses to start/end meetings. >>>> >>>> Max, is there anything to be done to make jbott more stable? >>> >>> jbott had been running for months without problems (at least none >>> known to me) - then there was >>> a network disconnect at neuchatel office which meant it was off for >>> a >>> bit and then came back on. >>> >>> I know that it has gotten slower at ending meetings, i.e. it now >>> takes some minutes >>> for it to upload instead of seconds as in past. I can look into >>> speeding that up if that is the >>> problem you are seeing. >>> >>> Is that what you are seeing ? >>> >>> /max From brmeyer at redhat.com Wed Jan 22 10:46:27 2014 From: brmeyer at redhat.com (Brett Meyer) Date: Wed, 22 Jan 2014 10:46:27 -0500 (EST) Subject: [hibernate-dev] Prepared statement for EAGER entity relations returning cursor not closed In-Reply-To: References: Message-ID: <1931022653.8986443.1390405587308.JavaMail.root@redhat.com> Levan, that's already corrected under https://hibernate.atlassian.net/browse/HHH-8811 and will be in 4.3.1. Brett Meyer Red Hat, Hibernate ORM ----- Original Message ----- From: "Levan Tsinadze" To: hibernate-dev at lists.jboss.org Sent: Tuesday, January 21, 2014 6:54:59 PM Subject: [hibernate-dev] Prepared statement for EAGER entity relations returning cursor not closed Hello everybody I found that after migrating from 4.2.8.Final to 4.3.0.Final, if I have several @OneToMany EAGER entity relations and select at least 500 rows I get ORA-01000: maximum open cursors exceeded JDBC exception for Oracle database (ojdbc 12.1.0.1) I think problem is in org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad method which calls (line 156, column 106) org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(ResultSet resultSet, Statement statement) method and this last method closes only passed ResultSet, not Statement. I also found that in 4.2.7.SP1 in such case is called org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(Statement statement) which closes as ResultSet as passed Statement. Sincerely, Levan Tsinadze _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Jan 22 13:56:39 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 22 Jan 2014 12:56:39 -0600 Subject: [hibernate-dev] Hibernate ORM 4.3.1.Final release Message-ID: <52E01467.2080706@hibernate.org> http://in.relation.to/Bloggers/HibernateORM431FinalRelease From guillaume.smet at gmail.com Thu Jan 23 08:08:25 2014 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 23 Jan 2014 14:08:25 +0100 Subject: [hibernate-dev] Make HibernatePersistenceProvider easier to extend Message-ID: 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 steve at hibernate.org Thu Jan 23 18:05:57 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 23 Jan 2014 17:05:57 -0600 Subject: [hibernate-dev] New parser bugs reported: HQLPARSER vs HHH ? In-Reply-To: References: Message-ID: <52E1A055.4050907@hibernate.org> I think duplication is better too, since at the moment these jira projects cover completely separate code bases. On 01/22/2014 02:32 AM, Sanne Grinovero wrote: > A forum user had some trouble with the current HQL parser: > > https://forum.hibernate.org/viewtopic.php?f=1&t=1030515 > > And since I've been slow to react, he went ahead and created a JIRA; I > think he's right about this, still then - as you can see from his > latest post - he felt unsure on where to open it, and it became > HQLPARSER-35. > > Since this is about the current parser, he's probably in the wrong > place, and there is a risk that the ORM team won't notice timely? but > I don't think I can blame him as it's probably confusing. > > My first impulse was to jump on JIRA and see if I could enable some > big fat warning on HQLPARSER to explain the difference, but actually > maybe it's better if the ORM team could start looking at new issues in > there as _actual_ issues? > > I'm thinking that while HQLPARSER matures, it should also incorporate > fixes/tests happening on the mainline parser: if there was a single > place to track defects of both I could "catch up" on ORM improvements > when working on it. > > So... should I move HQLPARSER-35 to HHH, or shall we leave it there ? > Maybe better to duplicate the issues? > > I'm voting for duplication, as they require either a fix or at least a > test applied to both projects, and we probably want to keep lifecycle > independent for a while longer. > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Jan 24 04:34:32 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 24 Jan 2014 09:34:32 +0000 Subject: [hibernate-dev] 1.0.0.Alpha6 released for HQLPARSER project Message-ID: I just uploaded a new release for the Parser project, to allow OGM and Infinispan to move on to the latest Hibernate Search release. Sanne From sanne at hibernate.org Fri Jan 24 07:23:16 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 24 Jan 2014 12:23:16 +0000 Subject: [hibernate-dev] New parser bugs reported: HQLPARSER vs HHH ? In-Reply-To: <52E1A055.4050907@hibernate.org> References: <52E1A055.4050907@hibernate.org> Message-ID: Ok, I've moved the reported issue to HHH, then created HQLPARSER-37. Could everyone please remember to create a matching issue on the HQLPARSER project when HQL parsing is involved in a core issue? On 23 January 2014 23:05, Steve Ebersole wrote: > I think duplication is better too, since at the moment these jira projects > cover completely separate code bases. > > On 01/22/2014 02:32 AM, Sanne Grinovero wrote: >> >> A forum user had some trouble with the current HQL parser: >> >> https://forum.hibernate.org/viewtopic.php?f=1&t=1030515 >> >> And since I've been slow to react, he went ahead and created a JIRA; I >> think he's right about this, still then - as you can see from his >> latest post - he felt unsure on where to open it, and it became >> HQLPARSER-35. >> >> Since this is about the current parser, he's probably in the wrong >> place, and there is a risk that the ORM team won't notice timely? but >> I don't think I can blame him as it's probably confusing. >> >> My first impulse was to jump on JIRA and see if I could enable some >> big fat warning on HQLPARSER to explain the difference, but actually >> maybe it's better if the ORM team could start looking at new issues in >> there as _actual_ issues? >> >> I'm thinking that while HQLPARSER matures, it should also incorporate >> fixes/tests happening on the mainline parser: if there was a single >> place to track defects of both I could "catch up" on ORM improvements >> when working on it. >> >> So... should I move HQLPARSER-35 to HHH, or shall we leave it there ? >> Maybe better to duplicate the issues? >> >> I'm voting for duplication, as they require either a fix or at least a >> test applied to both projects, and we probably want to keep lifecycle >> independent for a while longer. >> >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From igor at chub.in Sun Jan 26 14:28:57 2014 From: igor at chub.in (Igor Chubin) Date: Sun, 26 Jan 2014 21:28:57 +0200 Subject: [hibernate-dev] Named Prepared Statements Message-ID: <20140126192857.GA30627@chub.in> Hallo list, I'm writing a Hibernate-dialect for a DBMS, and I can't understand what is the best way to do some things. One of my questions: How can I configure in the dialect, that it must/must not use named prepared statements. For example, I have this in HQL: Query query = session.createQuery("update Student set studentName = :studentName" + " where studentId = :studentId"); query.setParameter("studentName", "Jack"); query.setParameter("studentId", 1); And in resulting SQL: update tutorials.student set STUDENT_NAME=? where STUDENT_ID=? Is it posible to use named prepared statements in the resulting SQL? And opposite: how do I say that my DBMS doesn't support prepared statements? Thank you very much! -- Igor Chubin From sanne at hibernate.org Mon Jan 27 04:14:22 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 27 Jan 2014 09:14:22 +0000 Subject: [hibernate-dev] merge on new entities In-Reply-To: <20140127090759.GC9557@hibernate.org> References: <20140127090759.GC9557@hibernate.org> Message-ID: Thanks! yes we got to that conclusion. The question came from Radim in Infinispan team attempting to figure out how to squeeze some more performance from the JPACacheStore from Infinispan. It's tricky that in Infinipan we don't know if something is a new entry or an update; I had a highly customized MySQL CacheStore which used the "INSERT OR UPDATE" statement, a non-standard feature from that DB which is very useful for this case. Could be interesting for Hibernate ORM to think of a JPA merge implementation which could take advantage of such custom extensions? Requires quite a different Dialect API. Sanne On 27 January 2014 09:07, Emmanuel Bernard wrote: > If the id is assigned, we do a select first. Not super efficient but > that's about the only thing you can do. From emmanuel at hibernate.org Mon Jan 27 04:38:30 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 27 Jan 2014 10:38:30 +0100 Subject: [hibernate-dev] merge on new entities In-Reply-To: References: <20140127090759.GC9557@hibernate.org> Message-ID: <20140127093830.GD9557@hibernate.org> We might, but to add to the complexity, Hibernate ORM uses "merge" plans to optimize the number of selects for a given object graph merged. A non associated object being merged might be more common though, not sure. On Mon 2014-01-27 9:14, Sanne Grinovero wrote: > Thanks! > yes we got to that conclusion. The question came from Radim in > Infinispan team attempting to figure out how to squeeze some more > performance from the JPACacheStore from Infinispan. > > It's tricky that in Infinipan we don't know if something is a new > entry or an update; I had a highly customized MySQL CacheStore which > used the "INSERT OR UPDATE" statement, a non-standard feature from > that DB which is very useful for this case. > > Could be interesting for Hibernate ORM to think of a JPA merge > implementation which could take advantage of such custom extensions? > Requires quite a different Dialect API. > > Sanne > > On 27 January 2014 09:07, Emmanuel Bernard wrote: > > If the id is assigned, we do a select first. Not super efficient but > > that's about the only thing you can do. From emmanuel at hibernate.org Mon Jan 27 04:50:41 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 27 Jan 2014 10:50:41 +0100 Subject: [hibernate-dev] Hibernate Search 4.5.0.CR1 on staging and not in prod Message-ID: <20140127095041.GE9557@hibernate.org> On the website, Staging has a commit related to HSearch's release. That commit is not on production. Is that expected? From sanne at hibernate.org Mon Jan 27 04:57:41 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 27 Jan 2014 09:57:41 +0000 Subject: [hibernate-dev] Hibernate Search 4.5.0.CR1 on staging and not in prod In-Reply-To: <20140127095041.GE9557@hibernate.org> References: <20140127095041.GE9557@hibernate.org> Message-ID: yes, sorry that took very long. as the blog isn't published yet, I still need to edit the commit with the final blog url. Took me ages to verify that this CR wouldn't break anything in the Infinispan integrations: several tests needed to be fixed and some issuses in Infinispan core prevented me to fix the tests (ISPN-3933) .. long round trip, everything just got merged an hour ago. Now we know it all works and I can proceed with the WildFly updates. Sanne On 27 January 2014 09:50, Emmanuel Bernard wrote: > On the website, Staging has a commit related to HSearch's release. That > commit is not on production. Is that expected? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Mon Jan 27 05:21:58 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 27 Jan 2014 11:21:58 +0100 Subject: [hibernate-dev] OGM depending on ORM 4.3 Message-ID: <20140127102158.GG9557@hibernate.org> To follow up on the PR migrating OGM to ORM 4.3. I think it is the right thing to do but I wonder whether we should do a tag / release of Hibernate OGM before that. So that people still using the JPA 2.0 series have a final version and a point for fork. What has happened between the latest OGM version and now - aside from a long time that is :) Emmanuel From gunnar at hibernate.org Mon Jan 27 05:32:44 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 27 Jan 2014 11:32:44 +0100 Subject: [hibernate-dev] OGM depending on ORM 4.3 In-Reply-To: <20140127102158.GG9557@hibernate.org> References: <20140127102158.GG9557@hibernate.org> Message-ID: Looking at the issues which have been addressed or are work in progress since the last release [1] I don't think we need a tag. Feature-wise we've primarily been working on CouchDB support (that needs some follow-up issues though and thus is not yet releasable imo), the option stuff (the first usage of it is CouchDB and associations for MongoDB where the PR still is pending) and named native queries (which has been done after the first changes for CouchDB). Based on that I'd say Beta4 is the last JPA 2.0 version and can serve as base for forks should anyone be interested in that. --Gunnar [1] https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%204.0.0.Beta5%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC 2014/1/27 Emmanuel Bernard > To follow up on the PR migrating OGM to ORM 4.3. I think it is the right > thing to do but I wonder whether we should do a tag / release of > Hibernate OGM before that. So that people still using the JPA 2.0 series > have a final version and a point for fork. > > What has happened between the latest OGM version and now - aside from a > long time that is :) > > 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 Jan 27 08:25:52 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 27 Jan 2014 13:25:52 +0000 Subject: [hibernate-dev] Released: Hibernate Search 4.5.0.CR1 Message-ID: Hello all, many good reason to upgrade! As for tradition, all details in the blog: http://in.relation.to/Bloggers/BetterPerformanceSimplerMassIndexerHibernateSearch450CR1Available Bests, Sanne From steve at hibernate.org Mon Jan 27 10:26:37 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 27 Jan 2014 09:26:37 -0600 Subject: [hibernate-dev] Object/Relational mapping XML processing moving forward Message-ID: <52E67AAD.10406@hibernate.org> Reference : https://hibernate.atlassian.net/browse/HHH-8893 https://hibernate.atlassian.net/browse/HHH-8894 I wanted to start a discussion around some planned changes relating to processing XML mapping files. The 2 issues above cover the bulk of the intent: 1) move to a single format for expressing object/relational mapping in XML, based on the JPA ORM XSD 2) combine that with transformations for numerous known formats to a definitive format for processing. The basic idea here is to have just one XML format that we actually process as input (StAX+JAXB). It would be a derivative of the latest JPA ORM XSD ("extended" for Hibernate-specifics). We would still accept numerous other forms (hbm.dtd, "straight" orm.xsd versions 1.0, 2.0, 2.1) and transform them to the "extended" schema. This transformation would be available on-the-fly as well as via a build-time task. This opens up the question of exactly how we want to mix the Hibernate-specifics in with the JPA entity-mappings schema types. For example we might want to take this opportunity to "clean up" the things we expose via XML, or unify them. For now, I'd like to just make this an open call for suggestions of things people would like to see changed in XML mappings. From gunnar at hibernate.org Mon Jan 27 11:44:29 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 27 Jan 2014 17:44:29 +0100 Subject: [hibernate-dev] [OGM] OGM-21 query support In-Reply-To: References: Message-ID: Hi Guillaume, We have been discussing this issue (OGM query support via EM) earlier today on IRC, as it's definitely one which we should fix soon. As you started to work on it, do you have something worth sharing, which e.g. someone else could take that as starting point? Thanks, --Gunnar 2013/11/6 Gunnar Morling > Hi, > > Maybe you could have OgmEntityManager implement > HibernateEntityManagerImplementor (its an interface, no class) and forward > it the HEMI methods to the wrapped EM instance? > > --Gunnar > > > > 2013/11/4 Guillaume SCHEIBEL > >> Hello, >> >> I have started to work on the support of the JPQL queries from the >> EntityManager and I'm facing some difficulties. >> I have look into the ORM as a start and so I have created >> >> public class OgmQueryImpl extends AbstractQueryImpl implements >> TypedQuery { ... } >> >> Therefore, the AbstractQueryImpl class needs a constuctor >> using HibernateEntityManagerImplementor. Because OgmEntityManager is >> directly implementing EntityManager it cannot be done directly (HEMI is an >> implementation of the EntityManager interface). >> >> So I've tried to switch OgmEntityManager to >> extend AbstractEntityManagerImpl (which is an implementation of >> HibernateEntityManagerImplementor) but now >> OgmEntityManager#getEntityManagerFactory() must return an instance >> of EntityManagerFactoryImpl. >> The point is OgmEntityManagerFactory is implementing EntityManagerFactory >> and HibernateEntityManagerFactory and not EntityManagerFactoryImpl. >> >> I don't want to change the complete class hierarchie if there is a better >> option / choice. >> >> So any thoughts ? >> >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gbadner at redhat.com Tue Jan 28 02:29:33 2014 From: gbadner at redhat.com (Gail Badner) Date: Tue, 28 Jan 2014 02:29:33 -0500 (EST) Subject: [hibernate-dev] New metamodel status In-Reply-To: <1399883955.9375913.1390891579923.JavaMail.root@redhat.com> Message-ID: <959234520.9383627.1390894173935.JavaMail.root@redhat.com> I've pushed my work to my fork. Here is where I'm tracking details: https://github.com/hibernate/hibernate-orm/wiki/Metamodel-Integration-Tasks. Repository details are in that document. It's a bit disorganized at the moment, I'll update after the meeting. Regards, Gail From steve at hibernate.org Tue Jan 28 12:35:39 2014 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 28 Jan 2014 11:35:39 -0600 Subject: [hibernate-dev] IRC Developers Meeting - 1/28 Message-ID: <52E7EA6B.9080107@hibernate.org> Main discussions were around: * new O/RM XSD and validation concepts * metamodel integration back into master branch [11:32] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-01-28-15.51.html [11:32] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-01-28-15.51.txt [11:32] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-01-28-15.51.log.html From gbadner at redhat.com Wed Jan 29 03:23:47 2014 From: gbadner at redhat.com (Gail Badner) Date: Wed, 29 Jan 2014 03:23:47 -0500 (EST) Subject: [hibernate-dev] New metamodel status In-Reply-To: <959234520.9383627.1390894173935.JavaMail.root@redhat.com> References: <959234520.9383627.1390894173935.JavaMail.root@redhat.com> Message-ID: <454747335.10359453.1390983827280.JavaMail.root@redhat.com> Steve and Brett, I've added some jira issues to https://github.com/hibernate/hibernate-orm/wiki/Metamodel-Integration-Tasks. Please take a look and see if what I merged into master looks OK for those issues. In some cases, I only did what was necessary to compile, so please complete merging what I missed. I'll be adding more issues to the list tomorrow. Thanks, Gail ----- Original Message ----- > From: "Gail Badner" > To: "hibernate-dev" > Sent: Monday, January 27, 2014 11:29:33 PM > Subject: [hibernate-dev] New metamodel status > > I've pushed my work to my fork. > > Here is where I'm tracking details: > https://github.com/hibernate/hibernate-orm/wiki/Metamodel-Integration-Tasks. > Repository details are in that document. > > It's a bit disorganized at the moment, I'll update after the meeting. > > Regards, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Jan 29 14:14:49 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 29 Jan 2014 19:14:49 +0000 Subject: [hibernate-dev] Hibernate Search 4.5.0.Final is released Message-ID: Hello all, Hibernate Search 4.5.0.Final is released; as usual all details can be found on our official blog: http://in.relation.to/Bloggers/WildFly8IntegrationJPA21ReadyHibernateSearch450FinalIsHere Bests, Sanne From steve at hibernate.org Wed Jan 29 21:42:26 2014 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 29 Jan 2014 20:42:26 -0600 Subject: [hibernate-dev] HHH-7164 : 5.0 SessionFactory building Message-ID: <52E9BC12.5010409@hibernate.org> Since the results of the discussions we had on this subject in Stockholm are lost I started documenting what I could remember of what I had planned here. It's still a work in progress (e.g. I'd really like to document all the "contributor" contracts and where they fit in). If y'all could chime in with any ideas or recollections I'd appreciate it. From steve at hibernate.org Fri Jan 31 15:14:55 2014 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 31 Jan 2014 14:14:55 -0600 Subject: [hibernate-dev] API/SPI in 5.0 Message-ID: <52EC043F.3080609@hibernate.org> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI methods that are no longer relevant. I think it is better to look at these individually. == Configuration I went ahead and made a preliminary decision here as I discussed in HHH-7164. The thinking is that we had some leeway here because Configuration had been deprecated (and pretty widely known to be deprecated based on StackOverflow and other sources). Basically I made Configuration a simple delegate to the new Metadata building code. I removed all the methods that exposed access to the org.hibernate.mapping objects that Configuration used to manage. --- == Integrator This one is a little tougher. In retrospect I think I would have just gone for a number of discrete contributor contracts. For example, usually Integrator is used to add event listeners, so an EventListenerContributor would have worked. Then I would have used Integrator as a grouping of contributors. == PersisterFactory (and persister constructors) Forms taking Configuration and org.hibernate.mapping objects should, imo, get removed. But I can live with deprecation if someone wants to "pound the table" for that. But realize that the Configuration+org.hibernate.mapping forms would not be called ever.