2013/12/16 Emmanuel Bernard <emman...@hibernate.org> > I think in this specific case it does make sense to have a global > setting and a specific one for the additional mongodb if we rephrase > then like think > > @StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be > AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY) > @StoreAssociationsInSeparateCollection //mongo specific >
I'm a bit concerned about this naming approach using verbs. It reads nicely here, but does it work as well for other cases? E.g. take the write concern option, @WriteConcern(ACKNOWLEDGED) seems very natural, how would that look with the verb- based style? I feel with a declarative style using nouns such as @AssociationStorage we may be on the safer side. BTW is that a generic setting or something dedicated to document > datastore. > Does it work for k/v? I think it does. > Does it work for GraphDBs? > I was wondering the same. Not sure about graph DBs, I guess not? > On Mon 2013-12-16 10:46, Gunnar Morling wrote: > > On a related note, Emmanuel raised the question whether to use the same > > option types for different data stores or not, i.e. should we use the > same > > @AssociationStorage annotation and enum for MongoDB and CouchDB? > > > > Currently there are the following strategies: > > > > * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY > > * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY > > > > So we have IN_ENTITY in both, but the other strategies don't directly map > > to each other. CouchDB doesn't have a notion of "collections", so > > ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB > > (considering the one and only document heap as the "global collection", > > whereas that maps to a specific "associations" collection for the MongoDB > > backend). > > > > So in a shared enum we might have values like these: IN_ENTITY, > > ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION. > > > > The latter would only be supported on MongoDB and raise an exception when > > used with CouchDB. To make the options usable for other document stores > as > > well, I think we should avoid datastore specific terms such as > "collection" > > in the enum values. > > > > As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT > on > > the shared enum (It seems quite save to assume that this makes sense in > > every document store). The MongoDB dialect could then provide an > additional > > option which allows to specify the store-specific collection vs. global > > collection aspect: > > > > @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum > > @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific > > annotation/enum > > > > I slightly prefer that last approach because it doesn't expose any > specific > > things on the shared contracts, although increasing the complexity a bit > by > > having two options for MongoDB. > > > > --Gunnar > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/12/16 Emmanuel Bernard <emman...@hibernate.org> > > > > > Only the CouchDB provider in the PR so far. But the idea is to move all > > > to that model. > > > > > > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote: > > > > Hi guys, > > > > > > > > That sounds nice. Are association storage strategies already using > this > > > new > > > > feature ? > > > > > > > > > > > > Guillaume > > > > > > > > > > > > 2013/12/13 Emmanuel Bernard <emman...@hibernate.org> > > > > > > > > > So currently in the pull request, we now have the following > > > > > > > > > > 1. property > entity > global > > > > > 2. for each level in 1., programmatic API beats annotation > > > > > > > > > > These are simple rules to understand and all it good. > > > > > > > > > > Now Gunnar tried to handle class inheritance, ie superclasses and > > > > > overridden methods. > > > > > And we do differ in what we consider the natural rules (or what it > > > > > should be). > > > > > > > > > > Here is how I think the rules should be: > > > > > > > > > > 1. property > entity > global > > > > > 2. for each level in 1., subclass > superclass and overridden > method > > > > > > parent method > > > > > 3. for each level (in 1 and 2), programmatic API beats annotation > > > > > > > > > > Here is how Gunnar thinks the rules should be: > > > > > > > > > > 1. metadata on a class > metadata on a superclass (whether it is > on a > > > > > property or the class) > > > > > 2. for each hierarchy level, property > entity > global > > > > > 3. for each level in 1 and 2, programmatic API beats annotation > > > > > > > > > > In more concrete words, > > > > > > > > > > @Option(1) > > > > > class A { > > > > > @Option(2) > > > > > public String getMe() {return null;} > > > > > } > > > > > > > > > > @Option(3) > > > > > class B extends A { > > > > > @Override > > > > > public String getMe() {return null;} > > > > > } > > > > > > > > > > In my world, B.getMe has Options(2). > > > > > In Gunnar's world, B.getMe() has @Option(3). > > > > > > > > > > To me, a property level is always more specific than an entity, > hence > > > my > > > > > interpretation. If someone has set a value on a given property, it > > > would > > > > > be dangerous to be "globally" overridden by a subclass. > > > > > > > > > > Thoughts? > > > > > > > > > > Emmanuel > > > > > > > > > > On Tue 2013-12-03 10:48, Gunnar Morling wrote: > > > > > > Hi, > > > > > > > > > > > > In the context of embedded associations for CouchDB [1], I'm > working > > > on > > > > > > support for configuring the association storage mode using our > new > > > option > > > > > > system [2]. I can see the following "axes" of configuration here: > > > > > > > > > > > > * via annotation > > > > > > - on an association property > > > > > > - on a type > > > > > > * via the option API > > > > > > - on an association property > > > > > > - on a type > > > > > > - on the global level > > > > > > * via a configuration property as given via OgmConfiguration, > > > > > > persistence.xml etc. > > > > > > * on super-types > > > > > > - via annotations or API > > > > > > - on the property or entity level > > > > > > > > > > > > I'm looking now for a sensible and comprehensible algorithm for > > > taking > > > > > > these sources of configuration into account and determining the > > > effective > > > > > > setting for a given association. This could be one way: > > > > > > > > > > > > 1) check API > > > > > > a) look for a setting given via the programmatic API for the > given > > > > > > property > > > > > > b) if the property is not configured, look for a setting given > for > > > the > > > > > > entity > > > > > > c) if the entity itself is not configured, repeat a) and b) > > > iteratively > > > > > > on super-types if present > > > > > > d) if no type from the hierarchy is configured look for the > global > > > > > setting > > > > > > > > > > > > 2) check annotations > > > > > > if no configuration could be found in 1), do the same for > > > annotations, > > > > > > i.e. > > > > > > a) look for configuration on the given property > > > > > > b) look for configuration on the given entity > > > > > > c) repeat a) and b) iteratively on super-types if present > > > > > > > > > > > > 3) take default value given via OgmConfiguration/persistence.xml > etc. > > > > > > > > > > > > This algorithm ensures that: > > > > > > * API configuration always takes precedence over annotation > > > > > configuration; > > > > > > e.g. if a super-type is configured via the API or the setting is > > > given on > > > > > > the API global level, any annotations are ignored > > > > > > * "More local" configuration takes precedence; i.e. a type's own > > > > > > configuration wins over configuration from super-types, > > > property-level > > > > > > configuration wins over entity-level configuration > > > > > > > > > > > > Note that any setting given via OgmConfiguration/persistence.xml > > > would be > > > > > > handled as last fallback option, i.e. any configuration given via > > > > > > annotations or the API would take precedence over that. I first > > > didn't > > > > > like > > > > > > that but I came to think it makes sense, if the property name > conveys > > > > > that > > > > > > semantics, e.g. "defaultAssociationStorageMode". > > > > > > > > > > > > Any other thoughts or alternative approaches around this? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > --Gunnar > > > > > > > > > > > > [1] https://hibernate.atlassian.net/browse/OGM-389 > > > > > > [1] https://hibernate.atlassian.net/browse/OGM-208 > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev