[hibernate-dev] [validator] Time to let go
Hi, I was wondering for quite some time what to do with the hibernate-validator-legacy module of the current Validator codebase. It contains the old Validator 3.x code which originally wanted to keep around. However, afaik there was no activity against it for months if not even for years. hibernate-validator-legacy slows down the overall build time, leads to confusions when you are searching for classes in the IDE and overall does not serve a real purpose. I see two alternatives. Create a final tag and remove the module or create a new git repo and move the code into there. Given that lack of activity I would suggest the first option. We can cross the bridge of creating a repo for it, if we ever decide for another legacy release. Thoughts? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [validator] Time to let go
The main reason for keeping it around is that the latest stable release of Seam still uses it. But the idea of tagging + deleting is find by me. BTW how do you split a Git repo? simply by cloning and removing what you don't want? On 17 janv. 2011, at 11:29, Hardy Ferentschik wrote: > Hi, > > I was wondering for quite some time what to do with the > hibernate-validator-legacy module of the current > Validator codebase. > It contains the old Validator 3.x code which originally wanted to keep > around. However, afaik there > was no activity against it for months if not even for years. > hibernate-validator-legacy slows down the overall build time, leads to > confusions when you are searching for > classes in the IDE and overall does not serve a real purpose. > > I see two alternatives. Create a final tag and remove the module or create > a new git repo and move the code into > there. Given that lack of activity I would suggest the first option. We > can cross the bridge of creating a repo > for it, if we ever decide for another legacy release. > > Thoughts? > > --Hardy > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [validator] Time to let go
On Mon, 17 Jan 2011 13:06:07 +0100, Emmanuel Bernard wrote: > The main reason for keeping it around is that the latest stable release > of Seam still uses it. > But the idea of tagging + deleting is find by me. Ok. I would hope though that any new release would use Validator 4 > BTW how do you split a Git repo? simply by cloning and removing what you > don't want? That would be the easiest approach. But I think if you want to do it properly you would have to use some git plumbing commands as well, eg filter-branch There is something on stackoverflow as well - http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [validator] Time to let go
On 17 janv. 2011, at 13:18, Hardy Ferentschik wrote: > On Mon, 17 Jan 2011 13:06:07 +0100, Emmanuel Bernard > wrote: > >> The main reason for keeping it around is that the latest stable release of >> Seam still uses it. >> But the idea of tagging + deleting is find by me. > > Ok. I would hope though that any new release would use Validator 4 :) > Probable, but unless you follow what they are doing, and remind them, there is no guaranty :) > >> BTW how do you split a Git repo? simply by cloning and removing what you >> don't want? > > That would be the easiest approach. But I think if you want to do it properly > you would have to use some git plumbing commands, eg filter-branch > True. That rewrites history though, right? Not sure it's something wanted. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Clever dirty checking for Hibernate Search
We can experiment with such approach but I am not sure that will work properly. Here are a couple of issues: - what about entities exposing data via fields - what if I poll data from an outside source and need that to be refreshed even if I do not change nor read the entity (there is one such example in Hibernate Search in Action (the available stock example). On 15 janv. 2011, at 11:15, Sanne Grinovero wrote: > Context: > As a follow-up on "HSEARCH-361 Only index an entity if an indexed > property has changed": > during development of this improvement we agreed to disable the > dirty-checking optimization in case a BoostStrategy or ClassBridge was > defined on the class; > we also considered the (unlikely) possibility that a FieldBridge could > access the full entity in some way, getting access to properties we > wouldn't expect (this case requires to disable the new feature). > > So to fully support proper dirty check,some ideas where proposed to > add some way for ClassBridge/BoostStratey/... to define from which > properties they are affected. > Even if these implementations could list all property names, there are > drawbacks: > 1) it breaks DRY. It's error prone, people could easily forget to > update the used-properties definition after fixing the main method. > 2) doesn't take into account branches in the implementation. Maybe in > some cases it's affected by A,B, in some others by A,C depending on > the value of A. > 3) pollutes all existing APIs. > > Considering these drawbacks, I'm wondering if instead of the entity we > could pass to these implementations a proxied entity which could > record exactly which properties are being accessed. > The index would be not considered dirty if accessed properties aren't, > so further Document processing can be skipped. > > I'd expect Hibernate core already has all required elements to > intercept and track access to managed entities? > > Cheers, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Clever dirty checking for Hibernate Search
2011/1/17 Emmanuel Bernard : > We can experiment with such approach but I am not sure that will work > properly. Here are a couple of issues: Yes I just tossed the idea on the table, not sure either how far it can get, but if it worked it would be a pretty nice API. > - what about entities exposing data via fields I hoped someone from this list could answer that. I'm understanding that field access won't prevent clever bytecode processors to detect access, but I don't know how far Hibernate goes in this direction. I think we could make it, but I'd prefer to explore these possibilities if Hibernate Core already had something similar to trigger dirtyness of properties. > - what if I poll data from an outside source and need that to be refreshed > even if I do not change nor read the entity (there is one such example in > Hibernate Search in Action (the available stock example). Right, we can't do much in this case. As always, we'll provide an option to hard-disable such optimizations both globally and at entity level. Sanne > > On 15 janv. 2011, at 11:15, Sanne Grinovero wrote: > >> Context: >> As a follow-up on "HSEARCH-361 Only index an entity if an indexed >> property has changed": >> during development of this improvement we agreed to disable the >> dirty-checking optimization in case a BoostStrategy or ClassBridge was >> defined on the class; >> we also considered the (unlikely) possibility that a FieldBridge could >> access the full entity in some way, getting access to properties we >> wouldn't expect (this case requires to disable the new feature). >> >> So to fully support proper dirty check,some ideas where proposed to >> add some way for ClassBridge/BoostStratey/... to define from which >> properties they are affected. >> Even if these implementations could list all property names, there are >> drawbacks: >> 1) it breaks DRY. It's error prone, people could easily forget to >> update the used-properties definition after fixing the main method. >> 2) doesn't take into account branches in the implementation. Maybe in >> some cases it's affected by A,B, in some others by A,C depending on >> the value of A. >> 3) pollutes all existing APIs. >> >> Considering these drawbacks, I'm wondering if instead of the entity we >> could pass to these implementations a proxied entity which could >> record exactly which properties are being accessed. >> The index would be not considered dirty if accessed properties aren't, >> so further Document processing can be skipped. >> >> I'd expect Hibernate core already has all required elements to >> intercept and track access to managed entities? >> >> Cheers, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [validator] Time to let go
Hi, I'm definitely for removing the legacy project, too. Given it will very likely never change again I think a new repo for it would do more harm than good, so I'm also preferring option 1. If it is for any reason still needed for Seam or similar we might remove the legacy module from the aggregator build for now, taking it out of the general Maven build and remove it once Seam has upgraded to HV 4.x Gunnar 2011/1/17 Emmanuel Bernard > > On 17 janv. 2011, at 13:18, Hardy Ferentschik wrote: > > > On Mon, 17 Jan 2011 13:06:07 +0100, Emmanuel Bernard < > emman...@hibernate.org> wrote: > > > >> The main reason for keeping it around is that the latest stable release > of Seam still uses it. > >> But the idea of tagging + deleting is find by me. > > > > Ok. I would hope though that any new release would use Validator 4 :) > > > > Probable, but unless you follow what they are doing, and remind them, there > is no guaranty :) > > > > >> BTW how do you split a Git repo? simply by cloning and removing what you > don't want? > > > > That would be the easiest approach. But I think if you want to do it > properly > > you would have to use some git plumbing commands, eg filter-branch > > > > True. That rewrites history though, right? Not sure it's something wanted. > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
