From emmanuel at hibernate.org Thu Jul 2 10:20:16 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 2 Jul 2009 16:20:16 +0200 Subject: [hibernate-dev] Development status of Hibernate Shards In-Reply-To: <3459a8b00906290214p2a90074pb0d227471b48b69f@mail.gmail.com> References: <3459a8b00906290207x1349a068w58997680aab15748@mail.gmail.com> <3459a8b00906290214p2a90074pb0d227471b48b69f@mail.gmail.com> Message-ID: Max Ross (lead) always wanted to support JPA before going final. And he needs the JPA 2 criteria API for that. Until then you won't see the beta out. Also he works for Google, so you might never see the beta out period :) On Jun 29, 2009, at 11:14, Ruben Jarque wrote: > Hello, > > Hibernate Shards is still in a beta version, and I have checked the > project has not had too much activity in the last two years. Are > expected new releases in a near future? Have the goals of the > project been integrated in other project? > > -- > Rub?n Jarque > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090702/981648b7/attachment.html From bburke at redhat.com Thu Jul 2 10:34:00 2009 From: bburke at redhat.com (Bill Burke) Date: Thu, 02 Jul 2009 10:34:00 -0400 Subject: [hibernate-dev] Development status of Hibernate Shards In-Reply-To: References: <3459a8b00906290207x1349a068w58997680aab15748@mail.gmail.com> <3459a8b00906290214p2a90074pb0d227471b48b69f@mail.gmail.com> Message-ID: <4A4CC558.7090603@redhat.com> You should take a look at the Teeid project. Its kinda overkill for doing just sharding, but there are some amazing things there that are eye-opening. http://jboss.org/teiid They have a hibernate dialect and such. Emmanuel Bernard wrote: > Max Ross (lead) always wanted to support JPA before going final. And he > needs the JPA 2 criteria API for that. Until then you won't see the beta > out. > Also he works for Google, so you might never see the beta out period :) > > On Jun 29, 2009, at 11:14, Ruben Jarque wrote: > >> Hello, >> >> Hibernate Shards is still in a beta version, and I have checked the >> project has not had too much activity in the last two years. Are >> expected new releases in a near future? Have the goals of the project >> been integrated in other project? >> >> -- >> Rub?n Jarque >> _______________________________________________ >> 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 -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From emmanuel at hibernate.org Thu Jul 2 14:33:42 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 2 Jul 2009 20:33:42 +0200 Subject: [hibernate-dev] Re: Wrong javadoc in Validator API In-Reply-To: References: Message-ID: Fixed thanks. On Jun 23, 2009, at 18:39, Hardy Ferentschik wrote: > Hi, > > I think there is another error in the Validator javadoc. Probably a > cut&paste error > > * @throws IllegalArgumentException if object is null, if > propertyName null, empty > * or not a valid object property > * or if null is passed to the > varargs groups > * @throws ValidationException if a non recoverable error happens > * during the validation process > */ > Set> validateValue(Class beanType, > String propertyName, Object value, Class... groups); > > IllegalArgumentException if object is null seems to be wrong. > Probably should be "if beanType is null". null as value seems to be > a valid case. > > --Hardy From emmanuel at hibernate.org Fri Jul 3 05:05:07 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 3 Jul 2009 11:05:07 +0200 Subject: [hibernate-dev] Batch indexing API In-Reply-To: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> References: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> Message-ID: Overall I think it's good. some proposals (when followed by a ? my feeling is that the original name is as good or better) Generally, I've inversed names to make the most important word first. Indexer => MassIndexer objectLoadingThreads => threadsToLoadObjects objectLoadingBatchSize => batchSizeToLoadObjects documentBuilderThreads => threadsForSubsequentFetching, threadsForFetching indexWriterThreads => threadsIndexingToLucene cacheMode //when would you need something different than Ignore? Also, I'd rather get CacheMode be a Search class to keep the independance wrt Hibernate Core optimizeAtEnd => optimizeOnFinish optimizeAfterPurge purgeAllAtStart => purgeBeforeIndexing ?, purgeAllOnStart, purgeOnStart limitObjects => indexObjectsUpTo, indexFirstObjectsUpTo, limitIndexedObjectsTo //what's the use case? start => Future should get actually return some stats? We can delay that but I don't like the JavaDoc claiming that we will always return null startAndWait => execute ? WTY? On Jun 30, 2009, at 16:18, Sanne Grinovero wrote: > Hello, > I need some comments about the batch indexing API, so that I can > stabilize it and write the documentation; > I might even blog about it :-) > > Here is the current sketch: > http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/Indexer.java?r=16967 > > Emmanuel I remember you wanted to give me directions to make this > "fluent", and you didn't like the method names. > ideas? > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Fri Jul 3 06:06:41 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 3 Jul 2009 12:06:41 +0200 Subject: [hibernate-dev] Fwd: [jsr-303-eg] Make payload optional References: <30438001-7C69-4A29-9619-E2D237868452@jboss.com> Message-ID: Begin forwarded message: > From: Emmanuel Bernard > Date: July 3, 2009 11:58:46 CEDT > To: Java Community Process JSR #303 Expert List > Subject: [jsr-303-eg] Make payload optional > Reply-To: jsr-303-eg at jcp.org > > I was talking to Mike Keith from Oracle the other day and he became > concerned at us adding more and more mandatory attributes to > constraint definitions. > > He was proposing to make the payload attribute optional. In other > words, custom annotations would not have to add this property, > though the spec would recommend it and all built-in annotations > would have it. > The idea is to keep life easy for constraint developers. > > I am sympathetic to the idea, anybody fiercely against? > > PS: Mike was also arguing for making groups optional but I am more > reluctant on that, groups has become an important mechanism in BV, > so I would keep that mandatory. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090703/0265defc/attachment.html From sanne.grinovero at gmail.com Sat Jul 4 14:59:51 2009 From: sanne.grinovero at gmail.com (Sanne Grinovero) Date: Sat, 4 Jul 2009 20:59:51 +0200 Subject: [hibernate-dev] Batch indexing API In-Reply-To: References: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> Message-ID: <50e5f6250907041159y3e8114e5if93cba18ec4b0fe5@mail.gmail.com> thanks, answering inline: 2009/7/3 Emmanuel Bernard : > Overall I think it's good. > some proposals (when followed by a ? my feeling is that the original name is > as good or better) > Generally, I've inversed names to make the most important word first. > > Indexer => MassIndexer fine > objectLoadingThreads => threadsToLoadObjects > objectLoadingBatchSize => batchSizeToLoadObjects > documentBuilderThreads => threadsForSubsequentFetching, threadsForFetching > indexWriterThreads => threadsIndexingToLucene agreed on all above > cacheMode //when would you need something different than Ignore? Also, I'd > rather get CacheMode be a Search class to keep the independance wrt > Hibernate Core Depending on the model it might be much faster using cache when the indexed entity is having a @ManyToOne+ at IndexedEmbedded relation to some entity having high probability to have been indexed already. Like book->nation of publishing : you might have millions of books, but just some hundreds of nations, if these nations need to be reloaded over and over lazily with a second query a cache helps. I'll wrap it to a Search specific enum like I've seen in Annotations? > optimizeAtEnd => optimizeOnFinish > optimizeAfterPurge > purgeAllAtStart => purgeBeforeIndexing ?, purgeAllOnStart, purgeOnStart I vote for "purgeAllOnStart", I like "purgeAll" to be consistent. > limitObjects => indexObjectsUpTo, indexFirstObjectsUpTo, > limitIndexedObjectsTo ?//what's the use case? Mostly testing and developing; I didn't have this in first design but having to test it often it came out that it was quite useful if I could just try the effect of some new Analyzer without having to reindex millions of records; Also during changes to the entities you might want to see the effect of adding some new field / search option without having to wait for hours. I could have deleted data from dev database, but I consider having this option a bit more flexible; Actually I can foresee some feature request to be able to restrict the data, but we can think about that later. For same reasoning we could leave this out for the moment, but it has been very useful for me. > start => Future should get actually return some stats? We can delay that but > I don't like the JavaDoc claiming that we will always return null I took that from the recommendations on the Future javadoc itself, but I agree with you it doesn't feel very good. I could return (like you suggest) a reference to the used IndexerProgressMonitor (see http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/batchindexing/IndexerProgressMonitor.java?r=16587 ) The API of the IndexerProgressMonitor will be a topic to discuss later (it is HSEARCH-370), for now there is one default impl which will log progress and some performance stats; that's why it is missing methods to retrieve the stats. > startAndWait => execute ? I preferred to stress the little difference with "start"; don't you think that having a "start" method and an "execute" method is not making it clear which one I should call? Sanne > > WTY? > > On ?Jun 30, 2009, at 16:18, Sanne Grinovero wrote: > >> Hello, >> I need some comments about the batch indexing API, so that I can >> stabilize it and write the documentation; >> I might even blog about it :-) >> >> Here is the current sketch: >> >> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/Indexer.java?r=16967 >> >> Emmanuel I remember you wanted to give me directions to make this >> "fluent", and you didn't like the method names. >> ideas? >> >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From emmanuel at hibernate.org Sun Jul 5 05:12:03 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Sun, 5 Jul 2009 11:12:03 +0200 Subject: [hibernate-dev] Batch indexing API In-Reply-To: <50e5f6250907041159y3e8114e5if93cba18ec4b0fe5@mail.gmail.com> References: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> <50e5f6250907041159y3e8114e5if93cba18ec4b0fe5@mail.gmail.com> Message-ID: <1DE78CC0-57B7-4537-AFA8-A0A02B0EDC1E@hibernate.org> >> cacheMode //when would you need something different than Ignore? >> Also, I'd >> rather get CacheMode be a Search class to keep the independance wrt >> Hibernate Core > Depending on the model it might be much faster using cache when the > indexed entity > is having a @ManyToOne+ at IndexedEmbedded relation to some entity > having high > probability to have been indexed already. > Like book->nation of publishing : you might have millions of books, > but just some hundreds > of nations, if these nations need to be reloaded over and over lazily > with a second query > a cache helps. > I'll wrap it to a Search specific enum like I've seen in Annotations? Did you try? It seems that the first level cache would load the nation object once per iteration. Provided that cacheMode is unfortunately a global setting for all entities, I'm wondering what's more efficient in the end. > >> optimizeAtEnd => optimizeOnFinish >> optimizeAfterPurge >> purgeAllAtStart => purgeBeforeIndexing ?, purgeAllOnStart, >> purgeOnStart > I vote for "purgeAllOnStart", I like "purgeAll" to be consistent. That's reasonable, my idea was to remove All to allow the implementation to evolve down the road should Lucene provide a more efficient solution to purge and create a new object but that's a far off bet. > >> limitObjects => indexObjectsUpTo, indexFirstObjectsUpTo, >> limitIndexedObjectsTo //what's the use case? > Mostly testing and developing; I didn't have this in first design but > having to test it often it came out that > it was quite useful if I could just try the effect of some new > Analyzer without having to reindex > millions of records; Also during changes to the entities you might > want to see the effect > of adding some new field / search option without having to wait for > hours. > I could have deleted data from dev database, but I consider having > this option a bit more flexible; > Actually I can foresee some feature request to be able to restrict the > data, but we can think about > that later. For same reasoning we could leave this out for the moment, > but it has been very useful for me. OK, let's mark this one as experimental, you seem to want more of the API. > >> start => Future should get actually return some stats? We can delay >> that but >> I don't like the JavaDoc claiming that we will always return null > I took that from the recommendations on the Future javadoc itself, but > I agree with you it doesn't feel very good. > I could return (like you suggest) a reference to the used > IndexerProgressMonitor > (see http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/batchindexing/IndexerProgressMonitor.java?r=16587 > ) > The API of the IndexerProgressMonitor will be a topic to discuss later > (it is HSEARCH-370), for now there is one default impl > which will log progress and some performance stats; that's why it is > missing methods to retrieve the stats. Let's think about that and return null for now, I just want to relax the strong statement in the javadoc > > >> startAndWait => execute ? > I preferred to stress the little difference with "start"; don't you > think that having a "start" method and an "execute" method > is not making it clear which one I should call? > I know that's why I put a ? :) From hibernate at ferentschik.de Mon Jul 6 05:19:33 2009 From: hibernate at ferentschik.de (Hardy Ferentschik) Date: Mon, 06 Jul 2009 11:19:33 +0200 Subject: [hibernate-dev] Fwd: [jsr-303-eg] Make payload optional In-Reply-To: References: <30438001-7C69-4A29-9619-E2D237868452@jboss.com> Message-ID: I think that making the payload attribute optional is ok, but I also vote against making the groups optional. As you say, it has become a very important mechanism. And really, how much harder do this requirements make it to develop constraints? --Hardy On Fri, 03 Jul 2009 12:06:41 +0200, Emmanuel Bernard wrote: >> I was talking to Mike Keith from Oracle the other day and he became >> concerned at us adding more and more mandatory attributes to >> constraint definitions. >> >> He was proposing to make the payload attribute optional. In other >> words, custom annotations would not have to add this property, >> though the spec would recommend it and all built-in annotations >> would have it. >> The idea is to keep life easy for constraint developers. >> >> I am sympathetic to the idea, anybody fiercely against? >> >> PS: Mike was also arguing for making groups optional but I am more >> reluctant on that, groups has become an important mechanism in BV, >> so I would keep that mandatory. Thoughts? From sanne.grinovero at gmail.com Tue Jul 7 04:49:43 2009 From: sanne.grinovero at gmail.com (Sanne Grinovero) Date: Tue, 7 Jul 2009 10:49:43 +0200 Subject: [hibernate-dev] Batch indexing API In-Reply-To: <1DE78CC0-57B7-4537-AFA8-A0A02B0EDC1E@hibernate.org> References: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> <50e5f6250907041159y3e8114e5if93cba18ec4b0fe5@mail.gmail.com> <1DE78CC0-57B7-4537-AFA8-A0A02B0EDC1E@hibernate.org> Message-ID: <50e5f6250907070149q4fa41da6lbc651fa2432500ab@mail.gmail.com> inline: 2009/7/5 Emmanuel Bernard : > >>> cacheMode //when would you need something different than Ignore? Also, >>> I'd >>> rather get CacheMode be a Search class to keep the independance wrt >>> Hibernate Core >> >> Depending on the model it might be much faster using cache when the >> indexed entity >> is having a @ManyToOne+ at IndexedEmbedded relation to some entity having >> high >> probability to have been indexed already. >> Like book->nation of publishing : you might have millions of books, >> but just some hundreds >> of nations, if these nations need to be reloaded over and over lazily >> with a second query >> a cache helps. >> I'll wrap it to a Search specific enum like I've seen in Annotations? > > Did you try? It seems that the first level cache would load the nation > object once per iteration. Provided that cacheMode is unfortunately a global > setting for all entities, I'm wondering what's more efficient in the end. > Well I'm sure that it's not the best setting for most cases, but yes I have tried it and there are some situations in which it gives a major performance boost, especially on complex models having many relations of this type; Also in this case the "first level cache" is very short lived, and every thread is having it's own... being short lived there's not a big chance to have a "first level cache hit"; at the opposite the second level cache makes sure all "lookup tables" are loaded once for the whole process. Also it makes only sense when using a real cache, properly configured, not the Hashtable one. >> >>> optimizeAtEnd => optimizeOnFinish >>> optimizeAfterPurge >>> purgeAllAtStart => purgeBeforeIndexing ?, purgeAllOnStart, purgeOnStart >> >> I vote for "purgeAllOnStart", I like ?"purgeAll" to be consistent. > > That's reasonable, my idea was to remove All to allow the implementation to > evolve down the road should Lucene provide a more efficient solution to > purge and create a new object but that's a far off bet. > ah well I suppose this is not the only API you'll have to change, should that happen :-) >> >>> limitObjects => indexObjectsUpTo, indexFirstObjectsUpTo, >>> limitIndexedObjectsTo ?//what's the use case? >> >> Mostly testing and developing; I didn't have this in first design but >> having to test it often it came out that >> it was quite useful if I could just try the effect of some new >> Analyzer without having to reindex >> millions of records; Also during changes to the entities you might >> want to see the effect >> of adding some new field / search option without having to wait for hours. >> I could have deleted data from dev database, but I consider having >> this option a bit more flexible; >> Actually I can foresee some feature request to be able to restrict the >> data, but we can think about >> that later. For same reasoning we could leave this out for the moment, >> but it has been very useful for me. > > OK, let's mark this one as experimental, you seem to want more of the API. > >> >>> start => Future should get actually return some stats? We can delay that >>> but >>> I don't like the JavaDoc claiming that we will always return null >> >> I took that from the recommendations on the Future javadoc itself, but >> I agree with you it doesn't feel very good. >> I could return (like you suggest) a reference to the used >> IndexerProgressMonitor >> (see >> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/batchindexing/IndexerProgressMonitor.java?r=16587 >> ) >> The API of the IndexerProgressMonitor will be a topic to discuss later >> (it is HSEARCH-370), for now there is one default impl >> which will log progress and some performance stats; that's why it is >> missing methods to retrieve the stats. > > Let's think about that and return null for now, I just want to relax the > strong statement in the javadoc > I'll remove the return javadoc, leaving it undocumented for know. >> >> >>> startAndWait => execute ? >> >> I preferred to stress the little difference with "start"; don't you >> think that having a "start" method and an "execute" method >> is not making it clear which one I should call? >> > > I know that's why I put a ? :) > thanks for the insight, Sanne From emmanuel at hibernate.org Tue Jul 7 05:02:50 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 7 Jul 2009 11:02:50 +0200 Subject: [hibernate-dev] Batch indexing API In-Reply-To: <50e5f6250907070149q4fa41da6lbc651fa2432500ab@mail.gmail.com> References: <50e5f6250906300718r4a265d94x488151b0cec279c6@mail.gmail.com> <50e5f6250907041159y3e8114e5if93cba18ec4b0fe5@mail.gmail.com> <1DE78CC0-57B7-4537-AFA8-A0A02B0EDC1E@hibernate.org> <50e5f6250907070149q4fa41da6lbc651fa2432500ab@mail.gmail.com> Message-ID: <629E59FA-E884-4362-9365-363AB9E0B639@hibernate.org> ok, go ahead what ever that means :). On Jul 7, 2009, at 10:49, Sanne Grinovero wrote: > inline: > > 2009/7/5 Emmanuel Bernard : >> >>>> cacheMode //when would you need something different than Ignore? >>>> Also, >>>> I'd >>>> rather get CacheMode be a Search class to keep the independance wrt >>>> Hibernate Core >>> >>> Depending on the model it might be much faster using cache when the >>> indexed entity >>> is having a @ManyToOne+ at IndexedEmbedded relation to some entity >>> having >>> high >>> probability to have been indexed already. >>> Like book->nation of publishing : you might have millions of books, >>> but just some hundreds >>> of nations, if these nations need to be reloaded over and over >>> lazily >>> with a second query >>> a cache helps. >>> I'll wrap it to a Search specific enum like I've seen in >>> Annotations? >> >> Did you try? It seems that the first level cache would load the >> nation >> object once per iteration. Provided that cacheMode is unfortunately >> a global >> setting for all entities, I'm wondering what's more efficient in >> the end. >> > > Well I'm sure that it's not the best setting for most cases, but yes I > have tried it > and there are some situations in which it gives a major performance > boost, > especially on complex models having many relations of this type; > Also in this case the "first level cache" is very short lived, and > every thread is having > it's own... being short lived there's not a big chance to have a > "first level cache hit"; > at the opposite the second level cache makes sure all "lookup tables" > are loaded once > for the whole process. > Also it makes only sense when using a real cache, properly configured, > not the Hashtable > one. > >>> >>>> optimizeAtEnd => optimizeOnFinish >>>> optimizeAfterPurge >>>> purgeAllAtStart => purgeBeforeIndexing ?, purgeAllOnStart, >>>> purgeOnStart >>> >>> I vote for "purgeAllOnStart", I like "purgeAll" to be consistent. >> >> That's reasonable, my idea was to remove All to allow the >> implementation to >> evolve down the road should Lucene provide a more efficient >> solution to >> purge and create a new object but that's a far off bet. >> > > ah well I suppose this is not the only API you'll have to change, > should that happen :-) > >>> >>>> limitObjects => indexObjectsUpTo, indexFirstObjectsUpTo, >>>> limitIndexedObjectsTo //what's the use case? >>> >>> Mostly testing and developing; I didn't have this in first design >>> but >>> having to test it often it came out that >>> it was quite useful if I could just try the effect of some new >>> Analyzer without having to reindex >>> millions of records; Also during changes to the entities you might >>> want to see the effect >>> of adding some new field / search option without having to wait >>> for hours. >>> I could have deleted data from dev database, but I consider having >>> this option a bit more flexible; >>> Actually I can foresee some feature request to be able to restrict >>> the >>> data, but we can think about >>> that later. For same reasoning we could leave this out for the >>> moment, >>> but it has been very useful for me. >> >> OK, let's mark this one as experimental, you seem to want more of >> the API. >> >>> >>>> start => Future should get actually return some stats? We can >>>> delay that >>>> but >>>> I don't like the JavaDoc claiming that we will always return null >>> >>> I took that from the recommendations on the Future javadoc itself, >>> but >>> I agree with you it doesn't feel very good. >>> I could return (like you suggest) a reference to the used >>> IndexerProgressMonitor >>> (see >>> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/batchindexing/IndexerProgressMonitor.java?r=16587 >>> ) >>> The API of the IndexerProgressMonitor will be a topic to discuss >>> later >>> (it is HSEARCH-370), for now there is one default impl >>> which will log progress and some performance stats; that's why it is >>> missing methods to retrieve the stats. >> >> Let's think about that and return null for now, I just want to >> relax the >> strong statement in the javadoc >> > I'll remove the return javadoc, leaving it undocumented for know. > >>> >>> >>>> startAndWait => execute ? >>> >>> I preferred to stress the little difference with "start"; don't you >>> think that having a "start" method and an "execute" method >>> is not making it clear which one I should call? >>> >> >> I know that's why I put a ? :) >> > > thanks for the insight, > Sanne From steve at hibernate.org Wed Jul 8 21:25:06 2009 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 08 Jul 2009 20:25:06 -0500 Subject: [hibernate-dev] Hibernate core 3.2.7 not on maven repo In-Reply-To: References: <1246237366.3330.13.camel@localhost.localdomain> Message-ID: <1247102706.2784.1.camel@localhost.localdomain> Someone wrote the poms for central. Pretty sure JBoss repo just got them from there... On Mon, 2009-06-29 at 09:33 +0300, Alaa Mohsen wrote: > Weird. Never suspected that, especially that all other 3.2.x (with > their POM files) already exist on JBOSS repo. > > > > On Mon, Jun 29, 2009 at 4:02 AM, Steve Ebersole > wrote: > It wont be added to any by us. 3.2.x does not use Maven to > build and it > was decided to not write/maintain a pom for 3.2.x for that > fact. > Certainly we could upload the jar, but the pom and its > transitive deps > is what is generally useful... > > > On Sun, 2009-06-28 at 19:24 +0300, Alaa Mohsen wrote: > > Hello All, > > Couldn't help to notice that Hibernate Core 3.2.7 which > was > > released on June 4th was not deployed to JBOSS maven > repository (and > > still isn't in central). When would this be added to JBOSS > repo? > > Thanks > > > > Regards > > Alaa Nassef > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- > Steve Ebersole > Hibernate.org > > > -- Steve Ebersole Hibernate.org From steve at hibernate.org Wed Jul 8 21:40:55 2009 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 08 Jul 2009 20:40:55 -0500 Subject: [hibernate-dev] Help with first patch In-Reply-To: References: <4A38BE13.9060600@redhat.com> <4A38EC92.6040805@redhat.com> Message-ID: <1247103655.2784.7.camel@localhost.localdomain> There is a "Developer Resources" page I started on the wiki @ https://www.hibernate.org/436.html But, well, we've all seen the stability of that site over the past few weeks... So I am trying to hols off on any changes to this kind of "project content" (as compared to more transitional community wiki content) until we get everything moved over to the new shiny (yet to be discovered unstable) JBoss infrastructure. As for adding a new database, well that is a particuklar rub with Maven itself and a particular point I am not happy about. Amazingly there seems to be no easy way to accomplish this seemingly simply feat in Maven. Instead the maven devs want you to set up your testsuite module such that yet another module depends on it and supplies the needed jars and hibernate/jdbc config... On Wed, 2009-06-17 at 10:47 -0400, Nikolas Everett wrote: > I have another question. The particular bug I wrote a > patch for only > comes up with MySQL. Is there some way to test > hibernate against > > > Yes. On Hibernate Core, you can override the > appliesTo(Dialect) method and return "true" for MySQL-based > dialects and false for the others. > > If I wanted to write a test that ensured that transactions aren't > accidentally committed during a polymorphic delete when a database > constraint is violated, where would I put it? > org.hibernate.test.ops.DeleteTest has a number of tests relating to > the delete operation but none of the mappings in the > org.hibernate.test.ops package have any joined-subclasses in them. > > I've attached a diagram of the schema I'd create. My test would: > > 1. Create a Child and a KeyHolder with a reference to it > 2. Commit > 3. Delete the Child > 4. Catch the expected constraint exception and fail if no exception > was thrown > 5. Query for the Child and ensure that its type is still Child and not > Parent > > Step 5 would fail for MySQL with InnoDB at this point. > > I think if I did override appliesTo(Dialect) it would be to make sure > that foreign key constraints and temp tables work for that dialect. I > know MyISAM doesn't support foreign key constraints and polymorphic > deletes aren't supported for Dialects that don't support temp tables. > > > Also I ended up testing Hibernate against mysql by: > 1. Adding a mysql5 profile to my ~/.m2/settings.xml which overrides > jdbc.url, jdbc.user, and jdbc.pass > 2. JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/ mvn -P mysql5 clean test > > That seemed to do the trick. It looks like the same tests fail for > mysql as for the rest of HSQLDB but I didn't do a very thorough check. > > Is there a web page with stuff like this? Its not super hard to > figure out, but it would be nice to spell it out explicitly. > > > > > MySQL? Just out of curiosity, is there a build farm > for hibernate that > covers all of the different databases like Postgres > has for operating > systems at > http://buildfarm.postgresql.org/cgi-bin/show_status.pl ? > > > There is a public Hudson (CI software) instance [1] which > should receive some attention in the next months. You may want > to check the job "hibernate-all-trunk" and ignore the others. > Also, note that this includes most Hibernate projects > (ANN/EM/Validator/Search/Validator/...), not only Core. > > [1] http://hudson.jboss.org/hudson/view/hibernate/ > > Neat. Its not quite as easy to see what is going on compared to the > Postgres one but its a good start. > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole Hibernate.org From emmanuel at hibernate.org Thu Jul 9 09:57:04 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 9 Jul 2009 15:57:04 +0200 Subject: [hibernate-dev] Hibernate Search alternative Directory distribution Message-ID: Here is the concall notes on how to cluster and copy Hibernate indexes using non file system approaches. Forget JBoss Cache, forget plain JGroups and focus on Infinispan Start with Infinispan in replication mode (the most stable code) and then try distribution. It should be interesting to test the dist algo and see how well L1 cache behaves in a search environment. For the architecture, we will try the following approach in decreasing interest )If the first one works like a charm we stick with it): 1. share the same grid cache between the master and the slaves 2. have a local cache on the master where indexing is done and manually copy over the chuncks of changed data to the grid This requires to store some metadata (namely the list of chunks for a given index and the lastupdate for each chunk) to implement the same algorithm as the one implemented in FSMaster/SlaveDirectoryProvider (incremental copy). 3. have a local cache on the master where indexing is done and manually copy over the chuncks of changed data to the grid. Each slave copy from the grid to a local version of the index and use the local version for search. When writing the InfinispanDirectory (inspired by the RAMDirectory and the JBossCacheDirectory), one need to consider than Infinispan has a flat structure. The key has to contain: - the index name - the chunk name Both with essentially be the unique identifier. Each chunk should have its size limited (Lucene does that already AFAIK) Question on the metadata. one need ot keep the last update and the list of chuncks. Because Infinispan is not queryable, we need to store that as metadata: - should it be on each chunk (ie last time on each chunk, the size of a chunk) - on a dedicated metadata chunk ie one metadata chunk per chunk + a chink containing the list - on a single metadata chunk (I fear conflicts and inconsistencies) On changes or read explore the use of Infinispan transaction to ensure RR semantic. Is it necessary? A file system does not guarantee that anyway. In the case of replication, make sure a FD back end can be activated in case the grid goes to the unreachable clouds of total inactivity. Question to Manik: do you have a cluster to play with once we reach this stage? Good luck Lukasz,a nd ask for help if you are stuck or unsure of a decision :) From manik at jboss.org Thu Jul 9 10:16:15 2009 From: manik at jboss.org (Manik Surtani) Date: Thu, 9 Jul 2009 15:16:15 +0100 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: References: Message-ID: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> On 9 Jul 2009, at 14:57, Emmanuel Bernard wrote: > Here is the concall notes on how to cluster and copy Hibernate > indexes using non file system approaches. > > Forget JBoss Cache, forget plain JGroups and focus on Infinispan > Start with Infinispan in replication mode (the most stable code) and > then try distribution. It should be interesting to test the dist > algo and see how well L1 cache behaves in a search environment. > For the architecture, we will try the following approach in > decreasing interest )If the first one works like a charm we stick > with it): > 1. share the same grid cache between the master and the slaves > 2. have a local cache on the master where indexing is done and > manually copy over the chuncks of changed data to the grid > This requires to store some metadata (namely the list of chunks for > a given index and the lastupdate for each chunk) to implement the > same algorithm as the one implemented in FSMaster/ > SlaveDirectoryProvider (incremental copy). > 3. have a local cache on the master where indexing is done and > manually copy over the chuncks of changed data to the grid. Each > slave copy from the grid to a local version of the index and use the > local version for search. > > When writing the InfinispanDirectory (inspired by the RAMDirectory > and the JBossCacheDirectory), one need to consider than Infinispan > has a flat structure. The key has to contain: > - the index name > - the chunk name > Both with essentially be the unique identifier. > Each chunk should have its size limited (Lucene does that already > AFAIK) > Question on the metadata. one need ot keep the last update and the > list of chuncks. Because Infinispan is not queryable, we need to > store that as metadata: > - should it be on each chunk (ie last time on each chunk, the size > of a chunk) > - on a dedicated metadata chunk ie one metadata chunk per chunk + a > chink containing the list > - on a single metadata chunk (I fear conflicts and inconsistencies) > > On changes or read explore the use of Infinispan transaction to > ensure RR semantic. Is it necessary? A file system does not > guarantee that anyway. > > In the case of replication, make sure a FD back end can be activated > in case the grid goes to the unreachable clouds of total inactivity. FD backend? I presume you mean a cache store. Have a look at the different cache stores we ship with, I reckon a FileCacheStore would do the trick for you. http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/CacheStore.html http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/file/FileCacheStore.html > Question to Manik: do you have a cluster to play with once we reach > this stage? The cluster team does have a set of lab servers used to test, benchmark, etc. You will need to "book" time on this cluster though since it is shared between JBC/Infinispan, JGroups and JBoss AS clustering devs. Cheers -- Manik Surtani manik at jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org From emmanuel at hibernate.org Thu Jul 9 11:45:47 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 9 Jul 2009 17:45:47 +0200 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> Message-ID: <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> On Jul 9, 2009, at 16:16, Manik Surtani wrote: >> >> In the case of replication, make sure a FD back end can be >> activated in case the grid goes to the unreachable clouds of total >> inactivity. > > FD backend? I presume you mean a cache store. Have a look at the > different cache stores we ship with, I reckon a FileCacheStore would > do the trick for you. > > http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/CacheStore.html > http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/file/FileCacheStore.html Yes I meant FS as FileSystem, but any backend would do (though DB would be a bad choice). From lukasz.moren at gmail.com Mon Jul 13 12:10:52 2009 From: lukasz.moren at gmail.com (=?ISO-8859-2?B?o3VrYXN6IE1vcmXx?=) Date: Mon, 13 Jul 2009 18:10:52 +0200 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> Message-ID: > > 1. share the same grid cache between the master and the slaves Infinispan has a flat structure. The key has to contain: - the index name - the chunk name Both with essentially be the unique identifier. I suppose in this idea all indexes are stored in a one single grid. What about one Infinispan grid per directory, similarly to RAMDirectory or FSDirectory? IMHO it could make some simplifications i.e. in metadata or key names. Are there any Infinispan drawbacks to have a high number of caches in the network? Sharing JGroups channels can help in that? _ Lukasz 2009/7/9 Emmanuel Bernard > > On Jul 9, 2009, at 16:16, Manik Surtani wrote: > > >>> In the case of replication, make sure a FD back end can be activated in >>> case the grid goes to the unreachable clouds of total inactivity. >>> >> >> FD backend? I presume you mean a cache store. Have a look at the >> different cache stores we ship with, I reckon a FileCacheStore would do the >> trick for you. >> >> >> http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/CacheStore.html >> >> http://infinispan.sourceforge.net/4.0/apidocs/org/infinispan/loaders/file/FileCacheStore.html >> > > Yes I meant FS as FileSystem, but any backend would do (though DB would be > a bad choice). > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090713/a4d5fba0/attachment.html From manik at jboss.org Mon Jul 13 17:59:19 2009 From: manik at jboss.org (Manik Surtani) Date: Mon, 13 Jul 2009 22:59:19 +0100 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> Message-ID: <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> On 13 Jul 2009, at 17:10, ?ukasz More? wrote: > 1. share the same grid cache between the master and the slaves > > Infinispan has a flat structure. The key has to contain: > - the index name > - the chunk name > Both with essentially be the unique identifier. > > I suppose in this idea all indexes are stored in a one single grid. > What about one Infinispan grid per directory, similarly to > RAMDirectory or FSDirectory? IMHO it could make some simplifications > i.e. in metadata or key names. > Are there any Infinispan drawbacks to have a high number of caches > in the network? Sharing JGroups channels can help in that? They already share JGroups channels and other "heavy" components wherever possible. Its just that configuration becomes more of a pain, etc. When you say one cache per index, how do you define an index? Does 1 index mean all indexed data for a single java type? In which case couldn't these scale up dynamically and potentially on-demand? No wait - these are fixed in Hibernate Search on startup, correct? Cheers -- Manik Surtani manik at jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090713/bdfab041/attachment.html From emmanuel at hibernate.org Tue Jul 14 04:57:49 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 14 Jul 2009 10:57:49 +0200 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> Message-ID: On Jul 13, 2009, at 23:59, Manik Surtani wrote: > > On 13 Jul 2009, at 17:10, ?ukasz More? wrote: > >> 1. share the same grid cache between the master and the slaves >> >> Infinispan has a flat structure. The key has to contain: >> - the index name >> - the chunk name >> Both with essentially be the unique identifier. >> >> I suppose in this idea all indexes are stored in a one single grid. >> What about one Infinispan grid per directory, similarly to >> RAMDirectory or FSDirectory? IMHO it could make some >> simplifications i.e. in metadata or key names. >> Are there any Infinispan drawbacks to have a high number of caches >> in the network? Sharing JGroups channels can help in that? > > They already share JGroups channels and other "heavy" components > wherever possible. Its just that configuration becomes more of a > pain, etc. > > When you say one cache per index, how do you define an index? Does > 1 index mean all indexed data for a single java type? In which case > couldn't these scale up dynamically and potentially on-demand? No > wait - these are fixed in Hibernate Search on startup, correct? Right for now they are fixed at startup time. I'm unclear what is easier really. One cache or multiple caches. Multiple configurations (if seen by the user) is a PITA on the other hand could provide some flexibility (ie one cache behavior != than another) but that's rarely needed very likely. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090714/31c8e616/attachment.html From lukasz.moren at gmail.com Wed Jul 15 11:05:22 2009 From: lukasz.moren at gmail.com (=?ISO-8859-2?B?o3VrYXN6IE1vcmXx?=) Date: Wed, 15 Jul 2009 17:05:22 +0200 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> Message-ID: To have access to this same Infinispan cache on all nodes (master and slaves) I have to create it from this same, single CacheManager. So there is difficulty how to distribute CacheManager to all nodes - something like singleton in a cluster. Is there some recommended option how to achieve that in our case? Lukasz 2009/7/14 Emmanuel Bernard > > On Jul 13, 2009, at 23:59, Manik Surtani wrote: > > > On 13 Jul 2009, at 17:10, ?ukasz More? wrote: > > 1. share the same grid cache between the master and the slaves > > > Infinispan has a flat structure. The key has to contain: > > - the index name > > - the chunk name > > Both with essentially be the unique identifier. > > > I suppose in this idea all indexes are stored in a one single grid. What > about one Infinispan grid per directory, similarly to RAMDirectory or > FSDirectory? IMHO it could make some simplifications i.e. in metadata or key > names. > Are there any Infinispan drawbacks to have a high number of caches in the > network? Sharing JGroups channels can help in that? > > > They already share JGroups channels and other "heavy" components wherever > possible. Its just that configuration becomes more of a pain, etc. > > When you say one cache per index, how do you define an index? Does 1 index > mean all indexed data for a single java type? In which case couldn't these > scale up dynamically and potentially on-demand? No wait - these are fixed > in Hibernate Search on startup, correct? > > > Right for now they are fixed at startup time. > I'm unclear what is easier really. One cache or multiple caches. Multiple > configurations (if seen by the user) is a PITA on the other hand could > provide some flexibility (ie one cache behavior != than another) but that's > rarely needed very likely. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090715/6cb8e81e/attachment.html From emmanuel at hibernate.org Wed Jul 15 11:22:40 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 15 Jul 2009 11:22:40 -0400 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> Message-ID: <1368EFFD-BF37-4BBD-9C18-7F170477C384@hibernate.org> I am not sure I understand. I assume that caches somehow have a unique identifier to recognize themselves in a cluster right? So you have a CacheManager created on each node and by this "unique identifier", you can add a cache node to a given grid. Infinitians, more infos? On Jul 15, 2009, at 11:05, ?ukasz More? wrote: > To have access to this same Infinispan cache on all nodes (master > and slaves) I have to create it from this same, single CacheManager. > So there is difficulty how to distribute CacheManager to all nodes - > something like singleton in a cluster. > Is there some recommended option how to achieve that in our case? > > Lukasz > > 2009/7/14 Emmanuel Bernard > > On Jul 13, 2009, at 23:59, Manik Surtani wrote: > >> >> On 13 Jul 2009, at 17:10, ?ukasz More? wrote: >> >>> 1. share the same grid cache between the master and the slaves >>> >>> Infinispan has a flat structure. The key has to contain: >>> - the index name >>> - the chunk name >>> Both with essentially be the unique identifier. >>> >>> I suppose in this idea all indexes are stored in a one single >>> grid. What about one Infinispan grid per directory, similarly to >>> RAMDirectory or FSDirectory? IMHO it could make some >>> simplifications i.e. in metadata or key names. >>> Are there any Infinispan drawbacks to have a high number of caches >>> in the network? Sharing JGroups channels can help in that? >> >> They already share JGroups channels and other "heavy" components >> wherever possible. Its just that configuration becomes more of a >> pain, etc. >> >> When you say one cache per index, how do you define an index? Does >> 1 index mean all indexed data for a single java type? In which >> case couldn't these scale up dynamically and potentially on- >> demand? No wait - these are fixed in Hibernate Search on startup, >> correct? > > Right for now they are fixed at startup time. > I'm unclear what is easier really. One cache or multiple caches. > Multiple configurations (if seen by the user) is a PITA on the other > hand could provide some flexibility (ie one cache behavior != than > another) but that's rarely needed very likely. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090715/979e2705/attachment.html From lukasz.moren at gmail.com Wed Jul 15 12:06:24 2009 From: lukasz.moren at gmail.com (=?ISO-8859-2?B?o3VrYXN6IE1vcmXx?=) Date: Wed, 15 Jul 2009 18:06:24 +0200 Subject: [hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution In-Reply-To: <1368EFFD-BF37-4BBD-9C18-7F170477C384@hibernate.org> References: <8B96D59A-2331-4B57-9FC5-1DB6B78A170D@jboss.org> <7A35F66C-5C9B-4EAA-90E2-D42559D706C3@hibernate.org> <889C3DE5-4C9B-44FC-A352-5786477AD8EA@jboss.org> <1368EFFD-BF37-4BBD-9C18-7F170477C384@hibernate.org> Message-ID: Ah, Yes that's right, it's ok now. W dniu 15 lipca 2009 17:22 u?ytkownik Emmanuel Bernard < emmanuel at hibernate.org> napisa?: > I am not sure I understand.I assume that caches somehow have a unique > identifier to recognize themselves in a cluster right? > So you have a CacheManager created on each node and by this "unique > identifier", you can add a cache node to a given grid. > > Infinitians, more infos? > > > On Jul 15, 2009, at 11:05, ?ukasz More? wrote: > > To have access to this same Infinispan cache on all nodes (master and > slaves) I have to create it from this same, single CacheManager. > So there is difficulty how to distribute CacheManager to all nodes - > something like singleton in a cluster. > Is there some recommended option how to achieve that in our case? > > Lukasz > > 2009/7/14 Emmanuel Bernard > >> >> On Jul 13, 2009, at 23:59, Manik Surtani wrote: >> >> >> On 13 Jul 2009, at 17:10, ?ukasz More? wrote: >> >> 1. share the same grid cache between the master and the slaves >> >> >> Infinispan has a flat structure. The key has to contain: >> >> - the index name >> >> - the chunk name >> >> Both with essentially be the unique identifier. >> >> >> I suppose in this idea all indexes are stored in a one single grid. What >> about one Infinispan grid per directory, similarly to RAMDirectory or >> FSDirectory? IMHO it could make some simplifications i.e. in metadata or key >> names. >> Are there any Infinispan drawbacks to have a high number of caches in the >> network? Sharing JGroups channels can help in that? >> >> >> They already share JGroups channels and other "heavy" components wherever >> possible. Its just that configuration becomes more of a pain, etc. >> >> When you say one cache per index, how do you define an index? Does 1 >> index mean all indexed data for a single java type? In which case couldn't >> these scale up dynamically and potentially on-demand? No wait - these are >> fixed in Hibernate Search on startup, correct? >> >> >> Right for now they are fixed at startup time. >> I'm unclear what is easier really. One cache or multiple caches. Multiple >> configurations (if seen by the user) is a PITA on the other hand could >> provide some flexibility (ie one cache behavior != than another) but that's >> rarely needed very likely. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090715/72167998/attachment.html From emmanuel at hibernate.org Thu Jul 16 09:27:21 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 16 Jul 2009 09:27:21 -0400 Subject: [hibernate-dev] @Cacheable In-Reply-To: <1247709711.13071.33.camel@localhost.localdomain> References: <5FCA4C28-C019-4339-9BD3-8B075E31572E@hibernate.org> <1247709711.13071.33.camel@localhost.localdomain> Message-ID: <081A392A-F474-488D-B367-B7FF85C1E2E3@hibernate.org> On Jul 15, 2009, at 22:01, Steve Ebersole wrote: > On Wed, 2009-07-15 at 16:26 -0400, Emmanuel Bernard wrote: >> The spec made an incursion into caching metadata and allow to cache >> some classes and not others. So far so good. But that includes the >> scenario where these classes are inside the same class hierarchy >> >> Case 1 >> >> @Cacheable(false) >> class Person {} >> >> @Cacheable(true) >> class customer extends Person {} >> >> Case 2 >> >> @Cacheable(true) >> class Person {} >> >> @Cacheable(false) >> class customer extends Person {} >> >> Can we support that? > We store hierarchy in a single region based on the root entity. In > other words, in this case Person is root entity; that is the cache > region for both Person and for Customer in this example. That's what > allows us to serve from the cache properly when they say "load > Person X" > given that that data might identify either a Person or a Customer. > Supporting this mixing would destroy that Hibernate feature and take a > lot of time to do so to boot. Let me try and parse that properly. Let's assume two scenarii: 1. we still enforce one region per class hierarchy in this case, would it hurt to have a given class / subclass not cached whereas others are? we are still looking for a single region 2. we don't enforce one region per class hierarchy in this case, we need to precompute the list of regions for a given class hierarchy and ask each region to answer the question the way Hibernate does today. I can see that as slow(er) Also you have more regions to start and that's the slowness you are referring to at boot time, right? > >> Second problem, they want "easy" caching ootb but do not define >> caching strategies. What would be a good caching strategy default >> if a >> class is marked as cached but no caching strategy is defined? > Well the answer as to the best default AccessStrategy to use is > unfortunately going to depend. It depends on the RegionFactory > defined > and various other configuration choices. > > Let's assume that user still needs to define the RegionFactory. I can > see delegating this choice to the defined RegionFactory. It would > still > depend on other variables like are we using some form of JTA-based > transactions and have access to the TransactionManager, etc. But its > much better than Hibernate code needing to intrinsically understand > the > capabilities of all RegionFactory impls (what about a custom > RegionFactory???). Maybe this looks something like a new > RegionFactory > method: AccessType getDefaultAccessType(???) (AccessType is the enum > for > TRANSACTIONAL, READ_ONLY, etc). Not sure what all we would need to > pass > in to the method; probably the TransactionFactory and the > TransactionmanagerLookup; others? I am concerned about the idea of having this value changing depending on your environment (JTA or not). Do you think this will provide values to customers or is it a marketing / shineware feature. > > > -- > Steve Ebersole > Hibernate.org > From emmanuel at hibernate.org Thu Jul 16 09:33:49 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 16 Jul 2009 09:33:49 -0400 Subject: [hibernate-dev] [BV] How can a Bean Validation provider have its own Validation implementation In-Reply-To: References: Message-ID: IM log If you look at the spec, I've [...] the implementation details. Anybody is free to "implement" the API Which is what we did for JPA-API, Persistence.java is implemented differently in Sun's and our implementation The spec defines the public (and protected) contract of the APIs incl Validation not the implementation Hardy Ferentschik what's about the test harness then? to be an official BV implementation you have to pass the tests against our javax.validation, right? Emmanuel Bernard I don't think so. you could put yours. actually that's the case because the test harness is supposed to test for sig conformance On Jul 16, 2009, at 06:08, Hardy Ferentschik wrote: > Hi, > > the current spec says section 4.4.5 Validation: > > "The Validation implementation provided by the Bean Validation > provider must not contain any non private attrib- > ute or method aside from the three public static bootstrap > methods: ... " > > Given that Validation is not an interface and part of the API - how > can an implementor provide its own implementation? > Shouldn't this whole pragraph be removed? > > --Hardy From steve at hibernate.org Thu Jul 16 10:08:04 2009 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Jul 2009 09:08:04 -0500 Subject: [hibernate-dev] @Cacheable In-Reply-To: <081A392A-F474-488D-B367-B7FF85C1E2E3@hibernate.org> References: <5FCA4C28-C019-4339-9BD3-8B075E31572E@hibernate.org> <1247709711.13071.33.camel@localhost.localdomain> <081A392A-F474-488D-B367-B7FF85C1E2E3@hibernate.org> Message-ID: <1247753284.2744.25.camel@localhost.localdomain> > Let's assume two scenarii: > 1. we still enforce one region per class hierarchy > in this case, would it hurt to have a given class / subclass not > cached whereas others are? > we are still looking for a single region In your examples the cache lookup for all entities in the Person hierarchy resolve to Person#ID. So would it "hurt"? No, I guess not. It's more just a thing that we need to be very careful about. Say we have your case-1 (person not cacheable, customer is cacheable); it would be natural to simply skip the cache lookup during Session.load( Person.class, id ) because Person is defined as not being cacheable; but of course we cant skip it, because that Person#id might in fact be a Customer. So really all that the @Cacheable(false) on Person is doing is stopping us from putting data into that region when we *know* it is that specific type/subtype. Is that useful? Dunno. Can't say it sounds useful. > 2. we don't enforce one region per class hierarchy > in this case, we need to precompute the list of regions for a given > class hierarchy and ask each region to answer the question the way > Hibernate does today. Don't like this at all. Don't think it really helps alleviate anything either. > I can see that as slow(er) > Also you have more regions to start and that's the slowness you are > referring to at boot time, right? by "time" I just meant effort. > I am concerned about the idea of having this value changing depending > on your environment (JTA or not). If we are forced to support this, it has to go this route. Not all of our integrations support all of our defined access types; and there is not currently a single access type that is supported by all. READ_ONLY is probably closest, but that's not going to be very useful in this usage. Next up is READ_WRITE, but again not all integrations support it. But perhaps I misunderstand your concerns. To me its natural that this default access-type change based on environment. > Do you think this will provide values to customers or is it a > marketing / shineware feature. I think you know my feelings on caching in general ;) -- Steve Ebersole Hibernate.org From hibernate at ferentschik.de Mon Jul 20 11:06:08 2009 From: hibernate at ferentschik.de (Hardy Ferentschik) Date: Mon, 20 Jul 2009 17:06:08 +0200 Subject: [hibernate-dev] Bean Validation PFD2 and Hibernate Validator 4 Beta2 Message-ID: Hi all, We just released Hibernate Validator 4 Beta2 which aligns with Bean Validation PFD2 (JSR 303 Specification 1.0.CR3). Get all the juicy details on in.relation.to - http://in.relation.to/12026.lace --Hardy From sanne.grinovero at gmail.com Wed Jul 22 04:14:10 2009 From: sanne.grinovero at gmail.com (Sanne Grinovero) Date: Wed, 22 Jul 2009 10:14:10 +0200 Subject: [hibernate-dev] Fences API to threadsafely initialize no-argument constructor objects Message-ID: <50e5f6250907220114o3373a144ta022c3eeddc587fb@mail.gmail.com> Hi Hardy, sorry for the late answer, I remember some discussions between us about the coming of an API to help us with threadsafe objects which couldn't use contructor initialization (and hence final fields) but wasn't able to find the API back I spoke about. The javadoc for jsr166y : http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ but the API I was most interested in somehow disappeared and I couldn't remember the name. It is called Fences (at list the article back) and is an extension of jsr166y Quoting part of the javadoc: "With care, a fence may be used to obtain the memory safety effects of final for a field that cannot be declared as final, because its primary initialization cannot be performed in a constructor, in turn because it is used in a framework requiring that all classes have a no-argument constructor. " http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html the problem is that jsr166y is a preview of the concurrency APIs of Java7, and as such can be backported (there's a jar already you could depend on to make it work on JDK 5 and 6), but the Fences rely on JVM support so they can't be backported: so they are not included in jsr166y. That makes it quite useless for Search and Bean Validation :-( but it's still interesting to read about it as Fences documentation is a good reference for all the pitfalls in design of a "framework requiring that all classes have a no-argument constructor". regards, Sanne From hibernate at ferentschik.de Wed Jul 22 04:22:39 2009 From: hibernate at ferentschik.de (Hardy Ferentschik) Date: Wed, 22 Jul 2009 10:22:39 +0200 Subject: [hibernate-dev] Fences API to threadsafely initialize no-argument constructor objects In-Reply-To: <50e5f6250907220114o3373a144ta022c3eeddc587fb@mail.gmail.com> References: <50e5f6250907220114o3373a144ta022c3eeddc587fb@mail.gmail.com> Message-ID: Hi Sanne, I remember we were talking about this. It's indeed interesting. Never heard about ot before. --Hardy On Wed, 22 Jul 2009 10:14:10 +0200, Sanne Grinovero wrote: > Hi Hardy, > sorry for the late answer, I remember some discussions between us > about the coming of an API to help us with threadsafe objects > which couldn't use contructor initialization (and hence final fields) > but wasn't able to find the API back I spoke about. > > The javadoc for jsr166y : > http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ > but the API I was most interested in somehow disappeared and I > couldn't remember the name. > It is called Fences (at list the article back) and is an extension of > jsr166y > Quoting part of the javadoc: > > "With care, a fence may be used to obtain the memory safety effects of > final for a field that cannot be declared as final, because its > primary initialization cannot be performed in a constructor, in turn > because it is used in a framework requiring that all classes have a > no-argument constructor. " > > http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html > > the problem is that jsr166y is a preview of the concurrency APIs of > Java7, and as such can be backported > (there's a jar already you could depend on to make it work on JDK 5 > and 6), but the Fences > rely on JVM support so they can't be backported: so they are not > included in jsr166y. > That makes it quite useless for Search and Bean Validation :-( but > it's still interesting to read about it > as Fences documentation is a good reference for all the pitfalls in > design of a "framework requiring that all classes have a no-argument > constructor". From hibernate at ferentschik.de Tue Jul 28 09:26:34 2009 From: hibernate at ferentschik.de (Hardy Ferentschik) Date: Tue, 28 Jul 2009 15:26:34 +0200 Subject: [hibernate-dev] Vacation till 17th of August Message-ID: Hi there, just letting you know that I will be on vacation as of now. Trying to reach me will be futile since I will be in the North of Sweden completely unplugged :) Enjoy! Hardy From emmanuel at hibernate.org Tue Jul 28 12:50:44 2009 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 28 Jul 2009 11:50:44 -0500 Subject: [hibernate-dev] Vacation till 17th of August In-Reply-To: References: Message-ID: <3CA472F4-4F14-4383-A3A8-D5A264C07AD4@hibernate.org> Enjoy! On Jul 28, 2009, at 08:26, Hardy Ferentschik wrote: > Hi there, > > just letting you know that I will be on vacation as of now. > Trying to reach me will be futile since I will be in the North of > Sweden > completely unplugged :) > > Enjoy! > Hardy > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From lukasz.moren at gmail.com Thu Jul 30 19:51:05 2009 From: lukasz.moren at gmail.com (=?ISO-8859-2?B?o3VrYXN6IE1vcmXx?=) Date: Fri, 31 Jul 2009 01:51:05 +0200 Subject: [hibernate-dev] Spliting Lucene segments in Infinispan Directory Message-ID: Hi, The JBoss Cache directory for Lucene splits each Lucene segment into pieces - chunks. Similar solutions exists in Lucene RamDirectory implementation. Are there some pros to use such splitting approach in Infinispan directory case? Some buffer size is recommended? Lukasz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090731/f53b9745/attachment.html