[hibernate-dev] Wishing to work on Hibernate's DDL capabilities
Hello everyone, During the last two weeks, I've been developing a small framework allowing to create mappings on the fly, all the while allowing existing sessions to "fail gracefully" (ie, if their session fails to find a previously mapped column or table, they try with a newer session). I don't use POJOs, so this makes it relatively easy. This means I have to do DDL on the fly. Steven Ebersole has pointed me to the Schema* classes in org.hibernate.hbm2ddl. The current abilities include adding a table, adding columns to a table and removing a table (a Configuration object with only the validated mapping of the table to drop will do the trick nicely). But the DDL capabilities are lacking: * Hibernate won't drop a column, by choice, and it currently doesn't give the user a choice because it cannot do so internally AFAICS; * it won't add indices when requested, even with hbm2ddl=update; And others. Steven has pointed to a Jira task talking about an overhaul of the Dialect abstract class and all its derivatives, because for one, the Dialect doesn't provide "purpose oriented" capabilities, just one big lump of methods. After looking at the code (3.3.1), I can see that this is the case: for instance, there's no separation between DML and DDL. I wish to help. But I'd like to know what you, seasoned Hibernate developers, would like to see. From the on, I'll put together proposals and, if one is accepted, I'll start working on it. I don't have one ready right now, the main reason for it being that I don't fully grasp the internal Hibernate architecture yet. Is there a class diagram available somewhere? Thanks, -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSearch: Using sharding and avoiding query on multiple shards
Hi Chase, sorry for the late answer; I've just looked at your code, it looks very good and I'd like to apply this patch if Emmanuel and Hardy agree? There are no tests in your patch to verify this is actually useful, do you have a good example of a ShardingProvider using it? (tests are not only used to test your code but also serve as examples and concept demos). Don't you think the DirectoryProvider names should be exposed, or are you able to create a nice sharding implementation without needing that? If you could add a testcase and documentation updates it would be even better and speed up the work ;-) Sanne 2009/6/8 Chase Seibert : > Sanne, > > Did you get a change to look at this? Thanks, > > -Chase > > > On Wed, Jun 3, 2009 at 4:08 PM, Chase Seibert > wrote: >> >> Sanne, >> >> I have implemented your suggestion for IndexShardingStrategy to optionally >> provide a set of DirectoryProviders BEFORE the search based on one or more >> FullTextFilters. Using this change, I was able to optimize my specific case >> to search only hitting the relevant shards. >> >> I have not yet implemented your labeled shard idea, nor your shard on enum >> idea. If we can agree on this change first, I think I can implement those on >> top of this. >> >> Please see attached svn .patch (diff) file. I have tested the patch on >> 3.1.1 and 3.2.0. Any feedback is welcome. >> >> -Chase >> >> >> On Wed, Jun 3, 2009 at 1:27 PM, Sanne Grinovero >> wrote: >>> >>> I am having a similar need in these days; this should be a very useful >>> feature, but I'd like more something I could use with the existing API >>> like >>> >>> enableFullTextFilter( "MyShardsSelectionStrategy" ).setParameter( ... ) >>> >>> a practical example: >>> enableFullTextFilter( "LanguageFilter" ).setParameter( "IT-it" ) >>> >>> The existing IndexShardingStrategy should be able to be smarter and >>> have something like >>> >>> DirectoryProvider[] getDirectoryProvidersForQuery( filters && options >>> ) >>> >>> So a smart ShardingStrategy could do some selections considering this. >>> >>> I'm currently using sharding to shard my index on 25 different >>> languages (using per-language stemmers), so this would >>> be useful but I'd especially need to be able to "label" my different >>> DirectoryProviders using String identifiers, >>> I'd suggest to add a getName() to the DirectoryProvider interface: I >>> would use that to store countrycodes and >>> keep a map in my ShardingStrategy, so I can >>> easily select the right DP when >>> the LanguageFilter is enabled. >>> >>> Another usage would be to shard an entity on an Enumerated property: >>> in this case an appropriate ShardingStrategy >>> could be provided by Search and auto-configured by reading the >>> possible enum values: that would be a very easy way >>> to enable sharding on an entity. >>> >>> Sanne >>> >>> 2009/6/3 Emmanuel Bernard : >>> > >>> > >>> > Begin forwarded message: >>> > >>> > From: chase.seibert+opensubscri...@gmail.com >>> > Date: June 3, 2009 09:21:21 PDT >>> > To: emman...@hibernate.org >>> > Subject: Re: Re: [hibernate-dev] HSearch: Using sharding and avoiding >>> > query >>> > on multiple shards >>> > Reply-To: chase.seibert+opensubscri...@gmail.com >>> > Emmanuel, >>> > >>> > Regarding HSEARCH-251, and >>> > >>> > http://www.opensubscriber.com/message/hibernate-dev@lists.jboss.org/9770383.html >>> > >>> > Being able to query just a single shard or subset of shards would be >>> > awesome. I was thinking of a similar API: >>> > >>> > IndexShardingStrategy: >>> > public DirectoryProvider[] >>> > getDirectoryProviderForShard(int shardNum); >>> > >>> > FullTextQuery: >>> > public void enableShardFilter(int shardNum); >>> > public void enableShardFilters(int[] shardNums); >>> > >>> > FullTextQuery.buildSearcher() would need to be modified to call >>> > getDirectoryProviderForShard() for each shardNum if shardNums are set, >>> > otherwise it should continue to use >>> > getDirectoryProvidersForAllShards(); >>> > >>> > Calling this API from a consumer's stand-point would look like: >>> > FullTextQuery fullTextQuery = >>> > fullTextSession.createFullTextQuery(luceneQuery, entityClass); >>> > fullTextQuery.enableShardFilter(5); >>> > fullTextQuery.list(); >>> > >>> > This could be changed to pass named shards easily. I could prototype >>> > this >>> > and submit a .patch if you are interested. >>> > >>> > -Chase >>> > >>> > -- >>> > This message was sent on behalf of >>> > chase.seibert+opensubscri...@gmail.com at >>> > openSubscriber.com >>> > >>> > http://www.opensubscriber.com/message/hibernate-dev@lists.jboss.org/9800518.html >>> > >>> > >>> > ___ >>> > 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/hibe
Re: [hibernate-dev] HSearch: Using sharding and avoiding query on multiple shards
Hi Chase, the problem I see is that if you have 3 customers having ids 34,35,202 you'll have to define 202 indexes but you're right it should be a separate change. The documentation of Hibernate Search is built from xml files contained in the sources, you'll find them in /src/main/docbook/en-US/modules Using maven for the build you'll get also all documentation built so you can see how what you write will look like in both PDF and HTML forms. Here are the detailed instructions: https://www.hibernate.org/462.html#A8 2009/6/9 Chase Seibert : > Sanne, > > See attached example of a IndexShardingStrategy and unit test. I was able to > satisfy my shading needs without named shards, though I would be open to > implementing that separately. > > In CustomerShardingStrategy, the index is broken into one shard per > customer. Each Document contains a customerID field, which is used as the > index for a local DirectoryProvider array. The number of shards should be at > least the max customerID. The implementation of > getDirectoryProvidersForQuery() looks for a Filter called "customer" that > also contains a customerID parameter, and returns the single > DirectoryProvider for that customer. > > What can I do to aid the documentation effort? Thanks, > > -Chase > > > On Tue, Jun 9, 2009 at 2:54 PM, Sanne Grinovero > wrote: >> >> Hi Chase, >> sorry for the late answer; I've just looked at your code, it looks >> very good and I'd like to apply this patch if Emmanuel and Hardy >> agree? >> >> There are no tests in your patch to verify this is actually useful, do >> you have a good example of a ShardingProvider using it? >> (tests are not only used to test your code but also serve as examples >> and concept demos). >> Don't you think the DirectoryProvider names should be exposed, or are >> you able to create a nice sharding implementation without needing >> that? >> >> If you could add a testcase and documentation updates it would be even >> better and speed up the work ;-) >> >> Sanne >> >> 2009/6/8 Chase Seibert : >> > Sanne, >> > >> > Did you get a change to look at this? Thanks, >> > >> > -Chase >> > >> > >> > On Wed, Jun 3, 2009 at 4:08 PM, Chase Seibert >> > wrote: >> >> >> >> Sanne, >> >> >> >> I have implemented your suggestion for IndexShardingStrategy to >> >> optionally >> >> provide a set of DirectoryProviders BEFORE the search based on one or >> >> more >> >> FullTextFilters. Using this change, I was able to optimize my specific >> >> case >> >> to search only hitting the relevant shards. >> >> >> >> I have not yet implemented your labeled shard idea, nor your shard on >> >> enum >> >> idea. If we can agree on this change first, I think I can implement >> >> those on >> >> top of this. >> >> >> >> Please see attached svn .patch (diff) file. I have tested the patch on >> >> 3.1.1 and 3.2.0. Any feedback is welcome. >> >> >> >> -Chase >> >> >> >> >> >> On Wed, Jun 3, 2009 at 1:27 PM, Sanne Grinovero >> >> wrote: >> >>> >> >>> I am having a similar need in these days; this should be a very useful >> >>> feature, but I'd like more something I could use with the existing API >> >>> like >> >>> >> >>> enableFullTextFilter( "MyShardsSelectionStrategy" ).setParameter( ... >> >>> ) >> >>> >> >>> a practical example: >> >>> enableFullTextFilter( "LanguageFilter" ).setParameter( "IT-it" ) >> >>> >> >>> The existing IndexShardingStrategy should be able to be smarter and >> >>> have something like >> >>> >> >>> DirectoryProvider[] getDirectoryProvidersForQuery( filters && >> >>> options >> >>> ) >> >>> >> >>> So a smart ShardingStrategy could do some selections considering this. >> >>> >> >>> I'm currently using sharding to shard my index on 25 different >> >>> languages (using per-language stemmers), so this would >> >>> be useful but I'd especially need to be able to "label" my different >> >>> DirectoryProviders using String identifiers, >> >>> I'd suggest to add a getName() to the DirectoryProvider interface: I >> >>> would use that to store countrycodes and >> >>> keep a map in my ShardingStrategy, so I can >> >>> easily select the right DP when >> >>> the LanguageFilter is enabled. >> >>> >> >>> Another usage would be to shard an entity on an Enumerated property: >> >>> in this case an appropriate ShardingStrategy >> >>> could be provided by Search and auto-configured by reading the >> >>> possible enum values: that would be a very easy way >> >>> to enable sharding on an entity. >> >>> >> >>> Sanne >> >>> >> >>> 2009/6/3 Emmanuel Bernard : >> >>> > >> >>> > >> >>> > Begin forwarded message: >> >>> > >> >>> > From: chase.seibert+opensubscri...@gmail.com >> >>> > Date: June 3, 2009 09:21:21 PDT >> >>> > To: emman...@hibernate.org >> >>> > Subject: Re: Re: [hibernate-dev] HSearch: Using sharding and >> >>> > avoiding >> >>> > query >> >>> > on multiple shards >> >>> > Reply-To: chase.seibert+opensubscri...@gmail.com >> >>> > Emmanuel, >> >>> > >> >>> > Regarding HSEARCH-251, and >> >>> > >> >>> > >> >
[hibernate-dev] HHH 869 (Collections of value type in the Criteria API).
Hello, I'm new to the list, so please forgive me if I miss some common netiquette that is expected on this list. I'd like to try to create a patch to solve 869, as well as support querying of collections of composite types. First, are there any guidelines of what I should and shouldn't do? I'd love to clean up the implementation of CriteriaQueryTranslator while I'm working in there, but if that would disqualify my patch, then of course I should avoid that ;-) Second, I'm having a little trouble finding the metadata I need to implement CriteriaQueryTranslator.getColumns() and CriteriaQueryTranslator.getType() for composite collections. By that point, I have access to: CollectionPersister, propertyName, and sqlAlias. CollectionPersister.getElementType() returns a CompositType that appears to be empty. Thanks, Daniel. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JPA 2
Sorry for the delay Adam. It depends what you are looking for: Pure compliance: - JPA 2 won't be final till sept '09 so nobody can be compliant till then - after JPA 2 is officially out, Sun tend to be late in giving the TCK to their licensees despite the fact that the RI has passed the TCK. Go figure. - it will take use a few weeks after the TCK is handed over to us to certify Same features / same APIs: - the annotations are mainly stable and we need to port the old Hibernate Annotations to the new Annotations - the criteria API is still getting refined a little bit We are targeting something like end of summer to get Hibernate on par with the spec (that can change of course) Feature equivalent: - we already have most of the APIs as Hibernate extensions - so you can technically benefit from what's in the spec (minor the typesafe criteria API) HTH Emmanuel On Jun 4, 2009, at 14:35, Adam Oren wrote: I work for a firm that's *very* interested in the enhancements in identity support, caching and JPQL enhancements. We really hope the spec closes soon. In what version are you currently planning to have JPA 2.0 support GA, and any idea on when that will be? Thanks!! Adam Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it out. ___ 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] Re: Pushing indexes through JGroups
Hi, I've finished task concerning JMS replacement with JGroups. The patch is attached. The general idea of pushing indexes through JG is assured, however there are issues to improve (i.e. flexible JG protocol stack configuration). Any review or advices would be welcome to make sure that I am not going into blind alley. Thanks, Lukasz 2009/5/27 Emmanuel Bernard > Lukasz, > I have been discussing with Manik on #3 and we think that JBoss Cache / > Infinispan are probably a better fit than plain JGroups for that as all the > plumbing will be configured for you. > When you reach this problem, let's revive this discussion. > > > On May 25, 2009, at 11:07, Hardy Ferentschik wrote: > > Hi, >> >> I talked with Łukasz about this last wekk. Definitely, #1 and #3. >> #2 I don't like either. >> >> The befefit of #3 would also be that one could drop the requirement of >> having a shared file system (NFS, NAS, ...) #3 should be quite easy to >> implement. Maybe easy to get started with. >> >> --Hardy >> >> On Mon, 25 May 2009 10:55:52 +0200, Emmanuel Bernard < >> emman...@hibernate.org> wrote: >> >> Hello >>> I am not sure this is where we should go, or at least, it depends. here >>> are three scenarii >>> >>> >>> #1 JMS replacement >>> If you want to use JGroups as a replacement for the JMS backend, then I >>> think you should write a jgroups backend. Check >>> org.hibernate.search.backend.impl.jms >>> In this case all changes are sent via JGroups to a "master". The master >>> could be voted by the cluster possibly dynamically but that's not necessary >>> for the first version. >>> >>> #2 apply indexing on all nodes >>> JGroups could send the work queue to all nodes and each node could apply >>> the change. >>> for various reasons I am not fan of this solution as it creates overhead >>> in CPU / memory usage and does nto scale very well from a theoretical PoV. >>> >>> #3 Index copy >>> this is what you are describing, copying the index using JGroups instead >>> of my file system approach. This might have merits esp as we could diminish >>> network traffic using multicast but it also require to rethink the master / >>> slave modus operandi. >>> Today the master copy on a regular basis a clean index to a shared >>> directory >>> On a regular basis, the slave go and copy the clean index from the shared >>> directory. >>> In your approach, the master would send changes to the slaves and slaves >>> would have to apply them "right away" (on their passive version) >>> >>> I think #1 is more interesting than #3, we probably should start with >>> that. #3 might be interesting too, thoughts? >>> >>> Emmanuel >>> >>> PS: refactoring is a fact of life, so feel free to do so. Just don't >>> break public contracts. >>> >>> On May 21, 2009, at 22:14, Łukasz Moreń wrote: >>> >>> Hi, I have few questions that concern using JGroups to copy index files. I think to create sender(for master) and receiver(slave) directory providers. Sender class mainly based on existing FSMasterDirectoryProvider, first create local index copy and send later to slave nodes (or send without copying, but that may cause lower performance?). To avoid code redundancy it would be good to refactor a little FSMasterDirectoryProvider class, so then I can use copying functionality in new DirectoryProvider and add sending one; or rather I should work around it? I do not understand completely how does the multithreading access to index file work. Does FileChannel class assure that, when index is copied and new Lucene works are pushed? >>> >> >> >> > JGroups_Backend_draft_10-06-2009.patch Description: Binary data ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH 869 (Collections of value type in the Criteria API).
On Tue, 2009-06-09 at 13:57 -0700, Daniel Pitts wrote: > Hello, > > I'm new to the list, so please forgive me if I miss some common > netiquette that is expected on this list. > > I'd like to try to create a patch to solve 869, as well as support > querying of collections of composite types. > > First, are there any guidelines of what I should and shouldn't do? > I'd love to clean up the implementation of CriteriaQueryTranslator > while I'm working in there, but if that would disqualify my patch, > then of course I should avoid that ;-) It is best to isolate fixes and cleanup. That way we know what exactly you did to fix an issue as opposed to cosmetic changes and can inspect them separately. Feel free to attach both. > Second, I'm having a little trouble finding the metadata I need to > implement CriteriaQueryTranslator.getColumns() and > CriteriaQueryTranslator.getType() for composite collections. By that > point, I have access to: CollectionPersister, propertyName, and > sqlAlias. CollectionPersister.getElementType() returns a CompositType > that appears to be empty. 1) I assume you mean ComponentType (I don't know of a CompositType) 2) what do you mean by empty? Is this a criterion/restriction you are trying to apply? > > Thanks, > Daniel. > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
RE: [hibernate-dev] HHH 869 (Collections of value type in the Criteria API).
> -Original Message- > From: Steve Ebersole > Sent: Tuesday, June 09, 2009 6:02 PM > On Tue, 2009-06-09 at 13:57 -0700, Daniel Pitts wrote: > > Hello, > > > > I'm new to the list, so please forgive me if I miss some common > > netiquette that is expected on this list. > > > > I'd like to try to create a patch to solve 869, as well as support > > querying of collections of composite types. > > > > First, are there any guidelines of what I should and shouldn't do? > > I'd love to clean up the implementation of CriteriaQueryTranslator > > while I'm working in there, but if that would disqualify my patch, > > then of course I should avoid that ;-) > It is best to isolate fixes and cleanup. That way we know > what exactly you did to fix an issue as opposed to cosmetic > changes and can inspect them separately. Feel free to attach both. That makes sense. If I submit a patch that basically refactors the CQT class, what might be considered when deciding on inclusion? > > > Second, I'm having a little trouble finding the metadata I need to > > implement CriteriaQueryTranslator.getColumns() and > > CriteriaQueryTranslator.getType() for composite > collections. By that > > point, I have access to: CollectionPersister, propertyName, and > > sqlAlias. CollectionPersister.getElementType() returns a > CompositType > > that appears to be empty. > 1) I assume you mean ComponentType (I don't know of a CompositType) You are correct. Typo on my part. > 2) what do you mean by empty? I mean the propertyNames, propertyTypes, etc.. Are all empty arrays. Maybe I've configured something incorrectly. I've added to the testsuite what I think will prove my changes correct. Would it make sense to post a patch here that only has my changes to the tests? > > Is this a criterion/restriction you are trying to apply? It can be, but it also may be a Projection. I'm hoping that I can stick to modifying only the CriteriaQueryTranslator class, but if I need to dive deeper, then so be it. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Wishing to work on Hibernate's DDL capabilities
On Tue, 2009-06-09 at 17:11 +0200, Francis Galiegue wrote:
> Hello everyone,
>
> During the last two weeks, I've been developing a small framework
> allowing to create mappings on the fly, all the while allowing
> existing sessions to "fail gracefully" (ie, if their session fails to
> find a previously mapped column or table, they try with a newer
> session). I don't use POJOs, so this makes it relatively easy.
>
> This means I have to do DDL on the fly. Steven Ebersole has pointed me
> to the Schema* classes in org.hibernate.hbm2ddl. The current abilities
> include adding a table, adding columns to a table and removing a table
> (a Configuration object with only the validated mapping of the table
> to drop will do the trick nicely). But the DDL capabilities are
> lacking:
>
> * Hibernate won't drop a column, by choice, and it currently doesn't
> give the user a choice because it cannot do so internally AFAICS;
> * it won't add indices when requested, even with hbm2ddl=update;
>
> And others.
>
> Steven has pointed to a Jira task talking about an overhaul of the
> Dialect abstract class and all its derivatives, because for one, the
> Dialect doesn't provide "purpose oriented" capabilities, just one big
> lump of methods. After looking at the code (3.3.1), I can see that
> this is the case: for instance, there's no separation between DML and
> DDL.
Well the JIRA[1] to which I pointed you does not really go into this
per-se. It is more talking about potentially changing the way DDL is
created to use a delegate. Currently what happens is that the mapping
objects (Table, Index, etc) all know how to create DDL there own DDL.
The tie-in with Dialect here is that they coordinate with the Dialect to
figure out its capabilities and syntax. What I'd rather see is an
externalization of this DDL rendering. There are many parts to this and
it is in no way trivial. But the basic "externalize the DDL generation
code" should not be overly complex.
I too had been considering some similar form of cleanup. The ones I had
considered were things like grouping together various "purpose oriented"
methods into componentized contracts. The ones I mentioned to you to
give example were the methods pertaining to a dialects IDENTITY support
and its sequence support. So I'd imagine something like:
public interface IdentitySupport {
public boolean supportsIdentityColumns();
public boolean supportsInsertSelectIdentity();
...
}
public interface SequenceSupport {
public boolean supportsSequences();
public boolean supportsPooledSequences();
...
}
The Dialect contract could then be changed to return these contracts.
But this is all really secondary to what you want to achieve. For your
purposes, you are really just interested in the DDL generator piece.
For that I had envisioned asking the Dialect to get its DDL generation
delegate; maybe something like:
class Dialect {
...
public DDLGenerator getDDLGenerator() {
return ...;
}
}
But I never got the chance to completely think this all through. There
are lots of design questions that need to be addressed. Stuff like does
the delegate contract allow for both create/drop and alter usages? Or
do we ask the Dialect for a delegate for each usage? At what
granularity do we generate DDL commands? And if say at the granularity
of each Table etc, how do we account for say a table DDL command which
includes creating the PK versus one that does not (and therefore needs
separate DDL)?
Anyway, that's about as far as I got.
[1] http://opensource.atlassian.com/projects/hibernate/browse/HHH-1083
--
Steve Ebersole
Hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
RE: [hibernate-dev] HHH 869 (Collections of value type in the Criteria API).
On Tue, 2009-06-09 at 18:18 -0700, Daniel Pitts wrote: > That makes sense. If I submit a patch that basically refactors the CQT > class, what might be considered when deciding on inclusion? You mean is regards to the "cleanup"? Well, whether it makes sense AFAIAC. > I mean the propertyNames, propertyTypes, etc.. Are all empty arrays. > Maybe I've configured something incorrectly. That would be my guess. What does the mapping look like? > > > > Is this a criterion/restriction you are trying to apply? > It can be, but it also may be a Projection. I'm hoping that I can stick > to modifying only the CriteriaQueryTranslator class, but if I need to > dive deeper, then so be it. Not sure yet. -- Steve Ebersole Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
