Emmanuel Bernard edited a comment on Bug OGM-208

Settings and impact on providers

Raw discussion between Sanne and me on the subject

[10/07/12 16:55:00] Emmanuel Bernard: About https://hibernate.onjira.com/browse/OGM-208
We will need a way to keep these metadata per property, probably a service of sort.
We will also need to express these metadata:
1. it could be free form annotations
2. it could be annotations that must be annotated with @OGMMetadata (this could even define the DatastoreProvider it is compatible with if we feel the need @OGMMetadata(for=MongoDBDatastoreProvider.class)

Any preference or thoughts on the subject?
[10/07/12 16:55:48] Sanne Grinovero: Shouldn't it be "abstracted" from the persistence implementor?
[10/07/12 16:56:25] Sanne Grinovero: I'm thinking that many options might be commong among all document-oriented stores
[10/07/12 16:56:34] Emmanuel Bernard: Some will indeed
[10/07/12 16:56:35] Sanne Grinovero: and also most are JSON based
[10/07/12 16:57:16] Sanne Grinovero: I like how JPA defines primary key autogenerations: can use auto-increment or sequence, or "auto".
[10/07/12 16:57:51] Sanne Grinovero: but of course sequence won't work on DBs not supporting it.. but it refines them to a family of backends via it's capabilities.
[10/07/12 16:58:34] Sanne Grinovero: Are we having good reasons to give up on that lovely approach?
[10/07/12 16:59:06] Emmanuel Bernard: Say you want to use the driver's unsafe approach for a given entity in MongoDB
[10/07/12 16:59:14] Emmanuel Bernard: how would you abstract such setting?
[10/07/12 16:59:30] Emmanuel Bernard: I hope only MongoDB is stupid enough to have such setting
[10/07/12 16:59:50] Sanne Grinovero: some non-typesafe option, like "hints" on queries?
[10/07/12 17:00:38] Sanne Grinovero: I actually don't like those non-typesafe options, but thinking loud about consistency..
[10/07/12 17:01:01] Emmanuel Bernard: so you would only get a generic annotation @DoStuff(String name, String value) that could be put on entities and properties?
[10/07/12 17:01:47] Sanne Grinovero: What other examples we have (on top of Unsafe)
[10/07/12 17:02:12] Sanne Grinovero: Also, is Unsafe really a per-entity option? isn't it just a connection option?
[10/07/12 17:04:01] Emmanuel Bernard: I can think of the following on the top of my head: unsafe, primary/secondary - ie where are queries executed, R / W quorum, a way to override the name of the inverse side property when embedded (today it's the object property name), the fact that an association info should be embedded or not
[10/07/12 17:05:49] Sanne Grinovero: By queries you mean those triggered by CRUD operations only right? Otherwise I think the option belongs to the Query hint literally.
[10/07/12 17:06:12] Emmanuel Bernard: no
[10/07/12 17:06:16] Emmanuel Bernard: all queries
[10/07/12 17:06:31] Sanne Grinovero: Why should that be defined on the entities itself?
[10/07/12 17:07:09] Emmanuel Bernard: Because the consistency level one wants seems to be associated to the data itself aka the entity
[10/07/12 17:07:25] Emmanuel Bernard: say I don't care if I lose a comment
[10/07/12 17:07:31] Emmanuel Bernard: but I care if I lose a blog post
[10/07/12 17:07:54] Sanne Grinovero: but the power of R/W quorum is that you define it per use case, not blindly tipying it statically to the entity.
[10/07/12 17:08:43] Sanne Grinovero: For example I never liked the @NamedQuery to be defined on entities, especially when they are not strictly related to that entity.
[10/07/12 17:08:47] Emmanuel Bernard: so you would have a programming model where you need to define the quorum of all operations?
[10/07/12 17:09:26] Emmanuel Bernard: and the quorum is not associated to a "flush" or a transaction but is different per data you look or change right?
[10/07/12 17:09:33] Sanne Grinovero: how would you deal with a query targeting multiple entities having a conflicting quorum option otherwise?
[10/07/12 17:10:19] Emmanuel Bernard: Do you know any quorum based nosql that let you have a cross entity query?
[10/07/12 17:10:31] Sanne Grinovero: We do
[10/07/12 17:10:37] Emmanuel Bernard: we are not quorum based
[10/07/12 17:10:59] Sanne Grinovero: no ok, but how should we solve a "select from Object" ?
[10/07/12 17:11:13] Sanne Grinovero: if the backend is quorum based?
[10/07/12 17:11:51] Emmanuel Bernard: In my mind, we can get the returned entities accurate but not necessarily an accurate list of entities
[10/07/12 17:11:56] Emmanuel Bernard: if you see what I mena
[10/07/12 17:12:01] Emmanuel Bernard: each entity can be consistent
[10/07/12 17:12:13] Emmanuel Bernard: not necessarily the query result as a whole
[10/07/12 17:12:42] Sanne Grinovero: se we'd load each entity type with it's own consistency options?
[10/07/12 17:12:48] Sanne Grinovero: I would expect we have a default ratio, configurable in SessionFactory configuration properties, and be able to specify a different value on a specific query.
[10/07/12 17:13:24] Emmanuel Bernard: That feels strange to me to apply the same ratio for unrelated entities frankly
[10/07/12 17:13:39] Emmanuel Bernard: but I don't have much experience in using quorum based tools
[10/07/12 17:13:57] Sanne Grinovero: well there might be no relations in Cassandra, but we might have a JOIN mapped on them.
[10/07/12 17:14:34] Sanne Grinovero: and when we get to that point, I think it should be easy for the user to figure out which quorum ratio is going to be used.
[10/07/12 17:15:03] Sanne Grinovero: Let me make an example via Hibernate Search : @Similarity
[10/07/12 17:15:11] Emmanuel Bernard: So you'd rather have this approach all the time
[10/07/12 17:15:34] Sanne Grinovero: that annotation is nowadays defined on an indexed entity, but if affects the index actually.
[10/07/12 17:15:37] Emmanuel Bernard: ie meaning my entity based approach is not useful in practice?
[10/07/12 17:16:01] Sanne Grinovero: So we have to add specific checks that differen entities sharing the index would always consistently share the same Similarity definition.
[10/07/12 17:16:17] Sanne Grinovero: [sorry let me finish, I think it's related]
[10/07/12 17:16:55] Sanne Grinovero: but that was a mistake as we now depend on the entities annotations to be scanned to be able to define how an IndexWriter should open index "animals", which creates a very complex bootup.
[10/07/12 17:17:22] Sanne Grinovero: It would have been much simpler to not allow a @Similarity annotation on the entities, but an index-level options in the configuration file.
[10/07/12 17:17:29] Sanne Grinovero: makes sense?
[10/07/12 17:18:38] Sanne Grinovero: For example the @NamedQuery need to be defined on entities, but it's weird that one can define queries which are unrelated with the specific antities they are defined on.
[10/07/12 17:19:25] Sanne Grinovero: "Emmanuel Bernard: ie meaning my entity based approach is not useful in practice?" << not sure what you mean..
[10/07/12 17:20:58] Emmanuel Bernard: I am not sure I agree with the idea of drawing parallel between similarity and r/w quorum
[10/07/12 17:21:19] Emmanuel Bernard: similarity is computed and encoded in the datastore and global per index
[10/07/12 17:21:52] Emmanuel Bernard: r/w quorum seems to be a balance between how much you care about your data and how much you care about freshness when you read your data
[10/07/12 17:21:59] Sanne Grinovero: right they are unrelated. My point is that it's dangerous to define some options on the Entity, when they are applied on a different kind of object (queries in this case).
[10/07/12 17:22:05] Emmanuel Bernard: the first point is per entity I'd venture
[10/07/12 17:22:13] Emmanuel Bernard: the second point is more per use case
[10/07/12 17:22:30] Sanne Grinovero: but r/w quorum is definitely per use case, not strictly per type.
[10/07/12 17:22:59] Emmanuel Bernard: I would be very sad if the user had to set the quorum all them time
[10/07/12 17:23:11] Sanne Grinovero: I'd be fine to define defaults to be used, especially when initialized related collections for example as that happens transparently
[10/07/12 17:23:11] Emmanuel Bernard: sould it be per session,
[10/07/12 17:23:12] Emmanuel Bernard: per flush
[10/07/12 17:23:40] Emmanuel Bernard: and again should the quorum be the same for 2 entities loaded in cascade?
[10/07/12 17:23:45] Emmanuel Bernard: by query or otherwise
[10/07/12 17:23:57] Emmanuel Bernard: you seem to imply that it would be the case
[10/07/12 17:24:23] Sanne Grinovero: yes a Session option looks good, read the flush time (so one could change it in the same open session)
[10/07/12 17:24:35] Sanne Grinovero: "and again should the quorum be the same for 2 entities loaded in cascade?" < very good point.
[10/07/12 17:24:51] Sanne Grinovero: I agree in that example, not necessarily.
[10/07/12 17:26:28] Sanne Grinovero: Definitely defining it on entity relations make the API simpler. But how can I override it?
[10/07/12 17:26:38] Sanne Grinovero: (on use-case base)
[10/07/12 17:27:32] Emmanuel Bernard: is your argument that such entity level setting should be overridable per use case - let's say session
[10/07/12 17:27:47] Emmanuel Bernard: or is that it should not be settable per entity at all?
[10/07/12 17:28:06] Sanne Grinovero: the first one. having a default on the entity sounds reasonable.
[10/07/12 17:28:18] Emmanuel Bernard: or are you just fooling around to make my headache bigger
[10/07/12 17:28:35] Emmanuel Bernard: I agree with that
[10/07/12 17:28:42] Emmanuel Bernard: it should be overridable
[10/07/12 17:28:49] Sanne Grinovero: But having override capabilities casts a shade on complexity in API, that's why I'm rasing a warning flag now
[10/07/12 17:28:52] Emmanuel Bernard: but before it's overridable, it should be settable
[10/07/12 17:28:55] Sanne Grinovero: as I'm not sure how that would look like
[10/07/12 17:29:33] Sanne Grinovero: Ok let's get back on the "how to set options" then? I mean generally, where quorum is just an example.
[10/07/12 17:30:08] Sanne Grinovero: Where you thinking about a single annotation to handle all special features of each NoSQL implementation?
[10/07/12 17:30:47] Emmanuel Bernard: No I was thinking of one annotation per feature
[10/07/12 17:31:08] Emmanuel Bernard: @EmbedAssociationIdsInDocument for example
[10/07/12 17:31:35] Sanne Grinovero: Haa nice.
[10/07/12 17:31:36] Emmanuel Bernard: This annotation might or might not have to be annotated @OGMMetadata
[10/07/12 17:31:42] Emmanuel Bernard: which was the question I had
[10/07/12 17:32:23] Sanne Grinovero: Ok but what's the point of @OGMMetadata(for=MongoDBDatastoreProvider.class) ?
[10/07/12 17:32:53] Sanne Grinovero: I would at least change that to @OGMMetadata(for=DataStoreTypes.KEY_VALUE_STORES)
[10/07/12 17:33:28] Emmanuel Bernard: I see two benefits:

  • separate in the doc generic settings from provider specific settings
  • possibly filter out metadata passed to the dialect
    [10/07/12 17:33:35] Sanne Grinovero: so that people can for example extend MongoDBDatastoreProvider
    [10/07/12 17:33:36] Emmanuel Bernard: the second point it not that important
    [10/07/12 17:34:26] Emmanuel Bernard: So you're against specialization, at least for now
    [10/07/12 17:34:26] Sanne Grinovero: +1
    [10/07/12 17:34:35] Emmanuel Bernard: which is fine by me
    [10/07/12 17:35:03] Sanne Grinovero: Well I still hope to plugin Redis inheriting most of the work done for Mongo, for example..
    [10/07/12 17:35:26] Sanne Grinovero: (well bad example as they are different.. let's say CouchDB v Mongo)
    [10/07/12 17:36:04] Emmanuel Bernard: yes in_entity and such will be inherited
    [10/07/12 17:36:12] Emmanuel Bernard: as they are conceptual settings
    [10/07/12 17:36:26] Emmanuel Bernard: the quorum to a great extend is also a conceptual setting
    [10/07/12 17:36:41] Emmanuel Bernard: unsafe is specific to mongodb though
    [10/07/12 17:37:23] Sanne Grinovero: exactly, so I agree the metadata annotatin is useful, I was just concerned about the specific class pointed to. Unless we define a set of interfaces that define the capabilities of each store, and point to the interface?
    [10/07/12 17:37:48] Sanne Grinovero: so "HasUnsafeOptions" would be an interface implemented by the MongoDBDatastoreProvider, and you point to that.
    [10/07/12 17:37:55] Sanne Grinovero: (to that interface)
    [10/07/12 17:38:42] Sanne Grinovero: so then we can have "MapReduceCapable" & "JSONCapable" kind of datastores, and one mixed interfaces as markers on new datastores.
    [10/07/12 17:38:55] Sanne Grinovero: s/mixed/mixes
    [10/07/12 17:40:00] Emmanuel Bernard: hum, I see, I'm a bit concerned about the complexity we put down the dialect
    [10/07/12 17:40:07] Emmanuel Bernard: but I guess that's inevitable
    [10/07/12 17:40:21] Emmanuel Bernard: I ahve to admit I thought they would be simpler than they are today
    [10/07/12 17:40:49] Sanne Grinovero: Alternatively, WDYT about the enum for the options? We still need to maintain somewhere which datastores are triggered by each enum.
    [10/07/12 17:41:34] Sanne Grinovero: I mean a function "@OGMMetadata(for=DataStoreTypes.KEY_VALUE_STORES) matched MonDBDatastoreProvider ?"
    [10/07/12 17:41:44] Sanne Grinovero: which somehow needs to deal with custom extensions of it.
    [10/07/12 17:42:55] Emmanuel Bernard: PS mongodb is not key/value store
    [10/07/12 17:43:25] Sanne Grinovero: ok that function returns "false", but we still need to implement the function..
    [10/07/12 17:43:27] Emmanuel Bernard: And you would have the provider list the enums it is sensitive to?
    [10/07/12 17:44:16] Sanne Grinovero: that might be a good idea. Otherwise one goes with the marker interfaces rather than enums.
    [10/07/12 17:44:54] Emmanuel Bernard: The problem I see with enum is that it will be polluted very quickly with tons of provier specific options
    [10/07/12 17:46:16] Sanne Grinovero: Yea, the enum won't have a new value for each specific option, just for each capability. So Key_Value might be generic, but HAS_UNSAFE_OPTION would need to be exposed too.
    [10/07/12 17:46:20] Emmanuel Bernard: hum hold on, I am mixing the annotation describing the feature and this for options
    [10/07/12 17:47:00] Sanne Grinovero: right as I just wrote.. but still you might need a specific value for some features. Not literally for each option, but still quite a bit.
    [10/07/12 17:47:22] Sanne Grinovero: hold on, a Visitor does the trick.
    [10/07/12 17:48:12] Sanne Grinovero: @OGMMetadata(appliesOn=CustomVisitableImplementor.class)
    [10/07/12 17:49:09] Sanne Grinovero: you pass the visitable to the datastore, it's the datastore itself responsible to say if it supports a specific annotation or not. This assumes all annotations are known to the datastore (i.e. defined in hibernate-ogm-core)
    [10/07/12 17:50:29] Emmanuel Bernard: What does this CustomVisitableImplementor.class look like?
    [10/07/12 17:51:59] Sanne Grinovero: should have a single method like "void accept(DataStoreCapabilities dsc, Annotation a) { dsc.accept( this, a ); }
    [10/07/12 17:52:15] Sanne Grinovero: sorry the second "accept" should be "visit"
    [10/07/12 17:52:56] Emmanuel Bernard: what does the .visit method do?
    [10/07/12 17:53:23] Sanne Grinovero: this gets forced by an interface let's say "OptionsAcceptsVisitor"
    [10/07/12 17:53:29] Sanne Grinovero: so that visit looks like:
    [10/07/12 17:54:17] Sanne Grinovero: visit( OptionsAcceptsVisitor, Annotation a) { //this code is in the DataStore itself, so it can tell you if it supports a or not}
    [10/07/12 17:54:29] Sanne Grinovero: The beauty lies in the fact that the visit could enforce the type
    [10/07/12 17:54:37] Sanne Grinovero: so it could be:
    [10/07/12 17:55:07] Sanne Grinovero: visit( SafeOptionAcceptsVisitor, Annotation a) { return true; }
    [10/07/12 17:56:01] Sanne Grinovero: as the accept method passes "this", so narrowing its type if the DataStoreCapabilities interface defines it.
    [10/07/12 17:56:08] Sanne Grinovero: We would then define it for most common options.
    [10/07/12 17:56:25] Sanne Grinovero: The less common options will have to read Annotation and switch on it.
    [10/07/12 17:57:31] Emmanuel Bernard: How would that be different than

    class MyNoSQLDatastoreProvider {
    List<? extends Annotation> acceptedOptions() { List<? extends Annotation> options = new ArrayList<>(); options.add(Unsafe.class); options.add(Quorum.class); return options }
    }
    [10/07/12 17:59:29] Emmanuel Bernard: Also what would we do if that visit true / false knowledge?
    [10/07/12 17:59:58] Sanne Grinovero: Basically that the visitor would buy you a way to "force" all dialects to answer / be prepared to deal with the important options (those which you define in the visit(specific type, annotation)
    [10/07/12 18:00:36] Sanne Grinovero: the true/false should be returned to the invoker, to say the option applies or not to it / is supported by the datastore.
    [10/07/12 18:00:52] Sanne Grinovero: line { dsc.accept( this, a ); } should have been
    [10/07/12 18:00:57] Sanne Grinovero: { return dsc.accept( this, a ); }
    [10/07/12 18:02:40] Sanne Grinovero: Downside is that ir requires a new method for the datastore to compile every time you add an option for which the return is mandatory. But that's the point too, to not forget to implement it.. Not sure you want that though.
    [10/07/12 18:04:20] Sanne Grinovero: Ah I'm wrong, the requirement to update all datastores is not true, as long as all options have a common interface we can define that to not accept unknown options by default.
    [10/07/12 18:05:56] Emmanuel Bernard: My head is still foggy but I think you lost me
    [10/07/12 18:06:27] Emmanuel Bernard: if it's compile time check, I can see the benefit even thugh that might be a bit too far
    [10/07/12 18:06:43] Emmanuel Bernard: If it's not compile time checked, then why build such a complex system
    [10/07/12 18:07:20] Emmanuel Bernard: Because in the end, the knowledge that a provider accept a given setting is only useful as a documentation for the user
    [10/07/12 18:07:31] Emmanuel Bernard: OGM does nto really care
    [10/07/12 18:07:42] Emmanuel Bernard: and won't raise an exception
    [10/07/12 18:08:11] Sanne Grinovero: Ok but that's a weakness too. if it's just untested documentation, how will you know it's correct?
    [10/07/12 18:08:13] Emmanuel Bernard: as it would limit what you could do to move from one provider to another witht he same codebase
    [10/07/12 18:08:15] Sanne Grinovero: (up to date)
    [10/07/12 18:08:47] Sanne Grinovero: I was assuming it could affect some decision in ogm-core too
    [10/07/12 18:09:01] Emmanuel Bernard: The only solution the somethin along the line you described where each provider must imeplement method for each option returning true or false
    [10/07/12 18:09:09] Emmanuel Bernard: but even that can be worked around
    [10/07/12 18:09:25] Emmanuel Bernard: if a provider decides to answer yes but lies
    [10/07/12 18:09:36] Sanne Grinovero: right
    [10/07/12 18:10:04] Emmanuel Bernard: More simple could be

class MyNoSQLDSP implement DSP {
CommonOptions getValidOptions {
return new MyNoSQLCommonOptions implements CommonOptions {
boolean acceptUnsafe() {return true;}
boolean acceptQuorum( return true;}
}
}
}
[10/07/12 18:10:18] Sanne Grinovero: It would be of marginal use as when you create one it won't compile until you answered the mandatory questions
[10/07/12 18:10:33] Sanne Grinovero: +1 that looks nice and effective
[10/07/12 18:10:37] Emmanuel Bernard: well
class MyNoSQLDSP implement DSP {
  CommonOptions getValidOptions {
     return new MyNoSQLCommonOptions implements CommonOptions {
         boolean accept(Unsafe ann) {return true;}
         boolean accept(Quorum ann) { return true;}
     }
  }
}
[10/07/12 18:11:31] Sanne Grinovero: second one is using the visitor thing I just described.. so which one are you considering?
[10/07/12 18:11:59] Sanne Grinovero: First one looks good to me too, might not read all annotation options but I guess that's not the point.
[10/07/12 18:12:19] Emmanuel Bernard: The problem with the first one is that there is no compile time correlation between the method and the annotation describing the option
[10/07/12 18:13:03] Emmanuel Bernard: the problem wit the second one is that we can't let the user use the state of the annotation as we won't pass the actual annotations put on the entities to them
[10/07/12 18:13:37] Sanne Grinovero: no, but in the second you have two alternatives: either you force all datastores to be updated when you introduce a new option, or you add a "boolean accept(Object ann) {return false;}" to catch the unknown options.
[10/07/12 18:13:39] Emmanuel Bernard: also I despise overloading
[10/07/12 18:14:21] Sanne Grinovero: I didn't understand " we won't pass the actual annotations put on the entities to them" .. why not?
[10/07/12 18:14:24] Emmanuel Bernard: But if you add "boolean accept(Object ann) {return false;}" then the provider implementor doe snto really know it is missing some settings
[10/07/12 18:14:43] Emmanuel Bernard: unless it manually temporarily removes the generic accept(OBject) impl
[10/07/12 18:15:01] Sanne Grinovero: I know that defeats compile time check, but you still have a nice typesafe Annotation to read.
[10/07/12 18:15:13] Sanne Grinovero: (when you support it)
[10/07/12 18:15:30] Sanne Grinovero: Imho it boils down to this question:
[10/07/12 18:15:41] Sanne Grinovero: do you want all datastores to break when adding a new option?
[10/07/12 18:15:46] Emmanuel Bernard: I have 30 options, 2000 entities with 10 properties each. 1/10 has OGM annotations on them => you wan to call the visitors 2000 times? or 30 times?
[10/07/12 18:16:57] Sanne Grinovero: don't think it matters much. Even 2000 would be very quick, sub nanosecond.
[10/07/12 18:17:23] Emmanuel Bernard: Well it would require us to walk through all the entity metamodel and run these visits
[10/07/12 18:17:30] Emmanuel Bernard: For no practical reason
[10/07/12 18:18:11] Sanne Grinovero: but a visitor optimises extremely well, it basically is a constant. doesn't concern me untile I see otherwise
[10/07/12 18:18:53] Sanne Grinovero: and this is only run at startup right?
[10/07/12 18:18:57] Emmanuel Bernard: Actually I'm wrong, it's the difference between never calling it and calling it 2000 times
[10/07/12 18:19:05] Emmanuel Bernard: The runtime does not care about the result
[10/07/12 18:19:26] Emmanuel Bernard: Tools might
[10/07/12 18:19:47] Emmanuel Bernard: or some annotation processor like tools might want to get this knowledge
[10/07/12 18:19:51] Emmanuel Bernard: and call these methods
[10/07/12 18:20:12] Sanne Grinovero: Worst case the invoker can cache this, but I think a CHM would be slower than invoking it again.
[10/07/12 18:20:29] Emmanuel Bernard: why do you want the result Sanne?
[10/07/12 18:21:03] Sanne Grinovero: to say yes/no this datastore support UNSAFE ?
[10/07/12 18:21:44] Emmanuel Bernard: In which use case do you want do ask that question?
[10/07/12 18:22:17] Sanne Grinovero: UNSAFE is the wrong example. let's say Map/Reduce vs. Native Joins? Transactions?
[10/07/12 18:23:54] Emmanuel Bernard: I see, not sure these should be driven by annotations
[10/07/12 18:24:10] Emmanuel Bernard: as they are intrinsic capabilities of the provider
[10/07/12 18:24:17] Sanne Grinovero: ah right.
[10/07/12 18:24:45] Sanne Grinovero: @EmbedAssociationIdsInDocument ?
[10/07/12 18:25:06] Sanne Grinovero: I (guess) some datastores won't be able to do that..
[10/07/12 18:25:39] Emmanuel Bernard: well some datastores might decide not to support hat because that's meaningless for them
[10/07/12 18:25:43] Emmanuel Bernard: liek Infinispan
[10/07/12 18:26:03] Emmanuel Bernard: until we have inplace load / append
[10/07/12 18:26:19] Sanne Grinovero: isn't that what started this discussion ?
[10/07/12 18:27:23] Emmanuel Bernard: Yes but I was concerned about how to expose it to the end user and we shifted the discussion into how the provider would respond whether or not it knew how to handle it
[10/07/12 18:27:50] Emmanuel Bernard: I think
[10/07/12 18:27:53] Emmanuel Bernard:
[10/07/12 18:28:14] Sanne Grinovero: So you want to annotate the @EmbedAssociationIdsInDocument with some meta-annotation to document it only?
[10/07/12 18:28:33] Emmanuel Bernard: to filter it
[10/07/12 18:28:36] Sanne Grinovero: I assumed it would affect runtime of ogm-core too
[10/07/12 18:29:03] Emmanuel Bernard: We won't pass / stock all annotations to our metadata provider service
[10/07/12 18:29:25] Sanne Grinovero: why not?
[10/07/12 18:29:31] Emmanuel Bernard: and we cna't read them all the time because of the nasty synchronize in the vm
[10/07/12 18:30:14] Sanne Grinovero: sure not read them all the time, but we can read them once at start time even if they are not supported right?
[10/07/12 18:30:45] Sanne Grinovero: I'm confused about what the Infinispan datastore is going to deal with a @EmbedAssociationIdsInDocument annotated collection?
[10/07/12 18:30:53] Sanne Grinovero: s/what/how
[10/07/12 18:30:59] Emmanuel Bernard: I guess memory wise that would boil down to the pointers pointing to the annotations
[10/07/12 18:31:09] Emmanuel Bernard: plus the structure storing them
[10/07/12 18:31:40] Sanne Grinovero: maybe, but Hardy is rewriting it all via Jandex anyway.
[10/07/12 18:31:52] Emmanuel Bernard: and?
[10/07/12 18:32:05] Emmanuel Bernard: Jandex magically store them in thin air?
[10/07/12 18:32:35] Sanne Grinovero: no, exactly my point: they are going to be read anyway as that's out of our control
[10/07/12 18:33:04] Sanne Grinovero: so even if you filter them, or if you don't filter them but then the store decides to ignore them, I see no difference
[10/07/12 18:35:21] Emmanuel Bernard: https://github.com/jbossas/jandex/blob/master/src/test/java/org/jboss/jandex/test/BasicTestCase.java
[10/07/12 18:35:39] Emmanuel Bernard: not exactly a typesafe and friendly API
[10/07/12 18:38:17] Sanne Grinovero: Cool they finally merged my patches in ANTLR 3.4.x
[10/07/12 18:38:34] Sanne Grinovero: getting me some hope
[10/07/12 18:46:28] Emmanuel Bernard: With ORM using Jandex are we going to force the user to add a build time phase to build the jandex index?
[10/07/12 18:46:38] Emmanuel Bernard: or are wegoing to build it at runtime
[10/07/12 18:46:39] Emmanuel Bernard: ?
[10/07/12 18:47:10] Sanne Grinovero: I think the way it works is that if an index exists it will use it, otherwise it will generate one at runtime.
[10/07/12 18:47:50] Sanne Grinovero: hopefully the runtime-built index will get reused in next bootup..
[10/07/12 18:52:05] Sanne Grinovero: ANTLR/master doesn't even compile
[10/07/12 18:52:16] Nicolas Helleringer: :s
[10/07/12 18:52:31] Emmanuel Bernard: hey it's run by the same guys who maintain the Infinispan test suite ;P
[10/07/12 18:52:45] Sanne Grinovero: me
[10/07/12 18:53:06] Sanne Grinovero: I think I'm the only one contributing to both (devil)
[10/07/12 18:55:09] Emmanuel Bernard: I think I'll need a chat with Hardy on Jandex tomorrow
[10/07/12 18:56:20] Emmanuel Bernard: It might be super fast and shit but it's totaly untype-safe so you don't know where you read @MyAnnotation for example.
[10/07/12 18:56:36] Emmanuel Bernard: Not sure if they add a typesafe facade in front of it
[10/07/12 18:56:52] Emmanuel Bernard: or if they will suffer big time when maintaining Hibernate OGM down the road
[10/07/12 18:59:28] Sanne Grinovero: there's a thread about this, Steve, Hardy and myself. I initially proposed them to hack in commons-annotations to maintains the same API for the moment but they had some good points against that.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira