[hibernate-dev] Filter activation

Hello, here's a 6-year old issue: https://hibernate.atlassian.net/browse/HHH-3815 That suggests to add another attribute on the @Filter annotation (something like activeByDefault=true). Can we have your oppinion on it? -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.

Re: [hibernate-dev] Filter activation

Well I like this idea (additional flag on @Filter) better the actual request (multi-valued config setting). And what about for the @FilterDef(inition)? One concern I have is, e.g., getting a collection with a filter enabled, now disabling a filter and then initializing the collection. That seems

Re: [hibernate-dev] Filter activation

Hi Steve, and thanks for your reply. I guess I have mis-understood what the real proposal was. Also, unfortunately I don't have enough knowledge of hibernate's internals and like you already mentioned this change will actually affect a lot of the code. My question was more to see what the hibernat

Re: [hibernate-dev] (no subject)

For runtime enhancement there is no change, we manage it internally. For build-time, legacy enhancement only offered an Ant task (there is a Maven plugin developed by another group; I will reach out to them about this). At the moment those folks would need to point to a new Ant task. We could

Re: [hibernate-dev] (no subject)

Hmm, looks like I might have been mistaken about the "external Hibernate Maven plugin". The only one I can find (cannot remember if this is the one I was thinking of) just does schema export. On Fri, Nov 13, 2015 at 8:11 AM Steve Ebersole wrote: > For runtime enhancement there is no change, we

Re: [hibernate-dev] Filter activation

Let's keep this on-list, please. Thanks! The issue, to be clear, is not auto-enabling filters.. No, the issues/concern is allowing enabled filters to be later disabled. On Fri, Nov 13, 2015 at 8:34 AM Petar Tahchiev wrote: > Hello, > > I'm just chatting with the spring-boot guys now and they a

Re: [hibernate-dev] (no subject)

Forgot to address this part... 5.1 will include the ability to define lazy attribute fetch groups, the development of which requires a lot of changes to the contracts called from bytecode enhancement. So rather than retrofit these changes back into the legacy enhancement code, I chose to simply

[hibernate-dev] Attribute laziness and caching

In reworking some of the support for bytecode-enhanced laziness, I started thinking deeper about this idea of partial caching of such entities. First and foremost, why do we even allow this? Essentially what happens is that we allow a user to partially load an entity, and then stick that partial

Re: [hibernate-dev] Attribute laziness and caching

Gah, hit send too soon :) This comes up because I am working on the idea of lazy attribute fetch groups. This means that the simple boolean that we used to store is no longer going to be sufficient. This ties in with the discussion I started the other day about using attribute indexes versus att

Re: [hibernate-dev] Hibernate documentation on GitHub

Hi, On Wed, Nov 11, 2015 at 02:36:13PM +, Steve Ebersole wrote: > I think it makes sense to host these on hibernate.org *after* we figure out > the version-specific content issues I brought up in Barcelona. What issues are you talking about. I know you want to link to different versions of t

Re: [hibernate-dev] Hibernate documentation on GitHub

On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik wrote: > Hi, > > On Wed, Nov 11, 2015 at 02:36:13PM +, Steve Ebersole wrote: > > I think it makes sense to host these on hibernate.org *after* we figure > out > > the version-specific content issues I brought up in Barcelona. > > What issues a

Re: [hibernate-dev] Attribute laziness and caching

I worry that this stuff may just not work too. The tests that tested this stuff all expected the the involved entities to be build time enhanced prior to launching the tests. Which of course they aren't. So all the tests for enhancement + caching have effectively been skipped for years. On Fri,

Re: [hibernate-dev] Attribute laziness and caching

So here is what I plan to do since I have heard no replies... I went ahead and migrated the tests using enhancement+caching to use the testing runtime enhancement capabilities Luis and I have built. On top of that I am going to start adding more detailed assertions. It does seem to me that even

[hibernate-dev] Sub entities and Multi-version support

I've been seeing many blogs and articles against single-version optimistic locking, which can cause a transaction to abort even if two concurrent transactions don't modify the same records. While dynamic updates can help, many fear to use it because of performance issues (for very large tables).