<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
#email-body { min-width: 30em !important; }
#email-page { padding: 8px !important; }
#email-banner { padding: 8px 8px 0 8px !important; }
#email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
#email-fields { padding: 0 8px 8px 8px !important; }
#email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
<tr valign="top">
<td id="email-page" style="padding:16px !important;">
<table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
<tr valign="top">
<td bgcolor="#3e4c4e" style="background-color:#3e4c4e;color:#ffffff;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://www.jboss.org/dms/hibernate/images/jira/jiraheader_hibernate.png" alt="" style="vertical-align:top;" /></td>
</tr><tr valign="top">
<td id="email-banner" style="padding:32px 32px 0 32px;">
<table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
<div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
<a class="user-hover" rel="emmanuel" id="email_emmanuel" href="https://hibernate.onjira.com/secure/ViewProfile.jspa?name=emmanuel" style="color:#6c797f;">Emmanuel Bernard</a>
edited a comment on <img src="https://hibernate.onjira.com/images/icons/bug.gif" height="16" width="16" border="0" align="absmiddle" alt="Bug"> <a style='color:#6c797f;text-decoration:none;' href='https://hibernate.onjira.com/browse/OGM-208'>OGM-208</a>
</div>
<div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
<a style='color:#6c797f;text-decoration:none;' href='https://hibernate.onjira.com/browse/OGM-208'><strong>Create facility for OGM core and Dialects to receive custom metadata (annotation, programmatic) associated to entities, properties or associations</strong></a>
</div>
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td id="email-fields" style="padding:0 32px 32px 32px;">
<table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
<tr valign="top">
<td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
<td>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr valign="top">
<td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
<div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><h3><a name="Settingsandimpactonproviders"></a>Settings and impact on providers</h3>
<p>Raw discussion between Sanne and me on the subject</p>
<p><span class="error">[10/07/12 16:55:00]</span> Emmanuel Bernard: About <a href="https://hibernate.onjira.com/browse/OGM-208">https://hibernate.onjira.com/browse/OGM-208</a><br/>
We will need a way to keep these metadata per property, probably a service of sort.<br/>
We will also need to express these metadata:<br/>
1. it could be free form annotations<br/>
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)</p>
<p>Any preference or thoughts on the subject?<br/>
<span class="error">[10/07/12 16:55:48]</span> Sanne Grinovero: Shouldn't it be "abstracted" from the persistence implementor?<br/>
<span class="error">[10/07/12 16:56:25]</span> Sanne Grinovero: I'm thinking that many options might be commong among all document-oriented stores<br/>
<span class="error">[10/07/12 16:56:34]</span> Emmanuel Bernard: Some will indeed<br/>
<span class="error">[10/07/12 16:56:35]</span> Sanne Grinovero: and also most are JSON based<br/>
<span class="error">[10/07/12 16:57:16]</span> Sanne Grinovero: I like how JPA defines primary key autogenerations: can use auto-increment or sequence, or "auto".<br/>
<span class="error">[10/07/12 16:57:51]</span> 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.<br/>
<span class="error">[10/07/12 16:58:34]</span> Sanne Grinovero: Are we having good reasons to give up on that lovely approach?<br/>
<span class="error">[10/07/12 16:59:06]</span> Emmanuel Bernard: Say you want to use the driver's unsafe approach for a given entity in MongoDB<br/>
<span class="error">[10/07/12 16:59:14]</span> Emmanuel Bernard: how would you abstract such setting?<br/>
<span class="error">[10/07/12 16:59:30]</span> Emmanuel Bernard: I hope only MongoDB is stupid enough to have such setting <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 16:59:50]</span> Sanne Grinovero: some non-typesafe option, like "hints" on queries?<br/>
<span class="error">[10/07/12 17:00:38]</span> Sanne Grinovero: I actually don't like those non-typesafe options, but thinking loud about consistency..<br/>
<span class="error">[10/07/12 17:01:01]</span> Emmanuel Bernard: so you would only get a generic annotation @DoStuff(String name, String value) that could be put on entities and properties?<br/>
<span class="error">[10/07/12 17:01:47]</span> Sanne Grinovero: What other examples we have (on top of Unsafe)<br/>
<span class="error">[10/07/12 17:02:12]</span> Sanne Grinovero: Also, is Unsafe really a per-entity option? isn't it just a connection option?<br/>
<span class="error">[10/07/12 17:04:01]</span> 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<br/>
<span class="error">[10/07/12 17:05:49]</span> Sanne Grinovero: By queries you mean those triggered by CRUD operations only right? Otherwise I think the option belongs to the Query hint literally.<br/>
<span class="error">[10/07/12 17:06:12]</span> Emmanuel Bernard: no<br/>
<span class="error">[10/07/12 17:06:16]</span> Emmanuel Bernard: all queries<br/>
<span class="error">[10/07/12 17:06:31]</span> Sanne Grinovero: Why should that be defined on the entities itself?<br/>
<span class="error">[10/07/12 17:07:09]</span> Emmanuel Bernard: Because the consistency level one wants seems to be associated to the data itself aka the entity<br/>
<span class="error">[10/07/12 17:07:25]</span> Emmanuel Bernard: say I don't care if I lose a comment<br/>
<span class="error">[10/07/12 17:07:31]</span> Emmanuel Bernard: but I care if I lose a blog post<br/>
<span class="error">[10/07/12 17:07:54]</span> 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.<br/>
<span class="error">[10/07/12 17:08:43]</span> Sanne Grinovero: For example I never liked the @NamedQuery to be defined on entities, especially when they are not strictly related to that entity.<br/>
<span class="error">[10/07/12 17:08:47]</span> Emmanuel Bernard: so you would have a programming model where you need to define the quorum of all operations?<br/>
<span class="error">[10/07/12 17:09:26]</span> Emmanuel Bernard: and the quorum is not associated to a "flush" or a transaction but is different per data you look or change right?<br/>
<span class="error">[10/07/12 17:09:33]</span> Sanne Grinovero: how would you deal with a query targeting multiple entities having a conflicting quorum option otherwise?<br/>
<span class="error">[10/07/12 17:10:19]</span> Emmanuel Bernard: Do you know <b>any</b> quorum based nosql that let you have a cross entity query?<br/>
<span class="error">[10/07/12 17:10:31]</span> Sanne Grinovero: We do <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 17:10:37]</span> Emmanuel Bernard: we are not quorum based<br/>
<span class="error">[10/07/12 17:10:59]</span> Sanne Grinovero: no ok, but how should we solve a "select from Object" ?<br/>
<span class="error">[10/07/12 17:11:13]</span> Sanne Grinovero: if the backend is quorum based?<br/>
<span class="error">[10/07/12 17:11:51]</span> Emmanuel Bernard: In my mind, we can get the returned entities accurate but not necessarily an accurate list of entities<br/>
<span class="error">[10/07/12 17:11:56]</span> Emmanuel Bernard: if you see what I mena<br/>
<span class="error">[10/07/12 17:12:01]</span> Emmanuel Bernard: each entity can be consistent<br/>
<span class="error">[10/07/12 17:12:13]</span> Emmanuel Bernard: not necessarily the query result as a whole<br/>
<span class="error">[10/07/12 17:12:42]</span> Sanne Grinovero: se we'd load each entity type with it's own consistency options?<br/>
<span class="error">[10/07/12 17:12:48]</span> 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.<br/>
<span class="error">[10/07/12 17:13:24]</span> Emmanuel Bernard: That feels strange to me to apply the same ratio for unrelated entities frankly<br/>
<span class="error">[10/07/12 17:13:39]</span> Emmanuel Bernard: but I don't have much experience in using quorum based tools<br/>
<span class="error">[10/07/12 17:13:57]</span> Sanne Grinovero: well there might be no relations in Cassandra, but we might have a JOIN mapped on them.<br/>
<span class="error">[10/07/12 17:14:34]</span> 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.<br/>
<span class="error">[10/07/12 17:15:03]</span> Sanne Grinovero: Let me make an example via Hibernate Search : @Similarity<br/>
<span class="error">[10/07/12 17:15:11]</span> Emmanuel Bernard: So you'd rather have this approach all the time<br/>
<span class="error">[10/07/12 17:15:34]</span> Sanne Grinovero: that annotation is nowadays defined on an indexed entity, but if affects the index actually.<br/>
<span class="error">[10/07/12 17:15:37]</span> Emmanuel Bernard: ie meaning my entity based approach is not useful in practice?<br/>
<span class="error">[10/07/12 17:16:01]</span> Sanne Grinovero: So we have to add specific checks that differen entities sharing the index would always consistently share the same Similarity definition.<br/>
<span class="error">[10/07/12 17:16:17]</span> Sanne Grinovero: <span class="error">[sorry let me finish, I think it's related]</span><br/>
<span class="error">[10/07/12 17:16:55]</span> 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.<br/>
<span class="error">[10/07/12 17:17:22]</span> 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.<br/>
<span class="error">[10/07/12 17:17:29]</span> Sanne Grinovero: makes sense?<br/>
<span class="error">[10/07/12 17:18:38]</span> 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.<br/>
<span class="error">[10/07/12 17:19:25]</span> Sanne Grinovero: "Emmanuel Bernard: ie meaning my entity based approach is not useful in practice?" << not sure what you mean..<br/>
<span class="error">[10/07/12 17:20:58]</span> Emmanuel Bernard: I am not sure I agree with the idea of drawing parallel between similarity and r/w quorum<br/>
<span class="error">[10/07/12 17:21:19]</span> Emmanuel Bernard: similarity is computed and encoded in the datastore and global per index<br/>
<span class="error">[10/07/12 17:21:52]</span> 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<br/>
<span class="error">[10/07/12 17:21:59]</span> 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).<br/>
<span class="error">[10/07/12 17:22:05]</span> Emmanuel Bernard: the first point is per entity I'd venture<br/>
<span class="error">[10/07/12 17:22:13]</span> Emmanuel Bernard: the second point is more per use case<br/>
<span class="error">[10/07/12 17:22:30]</span> Sanne Grinovero: but r/w quorum is definitely per use case, not strictly per type.<br/>
<span class="error">[10/07/12 17:22:59]</span> Emmanuel Bernard: I would be very sad if the user had to set the quorum all them time<br/>
<span class="error">[10/07/12 17:23:11]</span> Sanne Grinovero: I'd be fine to define defaults to be used, especially when initialized related collections for example as that happens transparently<br/>
<span class="error">[10/07/12 17:23:11]</span> Emmanuel Bernard: sould it be per session,<br/>
<span class="error">[10/07/12 17:23:12]</span> Emmanuel Bernard: per flush<br/>
<span class="error">[10/07/12 17:23:40]</span> Emmanuel Bernard: and again should the quorum be the same for 2 entities loaded in cascade?<br/>
<span class="error">[10/07/12 17:23:45]</span> Emmanuel Bernard: by query or otherwise<br/>
<span class="error">[10/07/12 17:23:57]</span> Emmanuel Bernard: you seem to imply that it would be the case<br/>
<span class="error">[10/07/12 17:24:23]</span> Sanne Grinovero: yes a Session option looks good, read the flush time (so one could change it in the same open session)<br/>
<span class="error">[10/07/12 17:24:35]</span> Sanne Grinovero: "and again should the quorum be the same for 2 entities loaded in cascade?" < very good point.<br/>
<span class="error">[10/07/12 17:24:51]</span> Sanne Grinovero: I agree in that example, not necessarily.<br/>
<span class="error">[10/07/12 17:26:28]</span> Sanne Grinovero: Definitely defining it on entity relations make the API simpler. But how can I override it?<br/>
<span class="error">[10/07/12 17:26:38]</span> Sanne Grinovero: (on use-case base)<br/>
<span class="error">[10/07/12 17:27:32]</span> Emmanuel Bernard: is your argument that such entity level setting should be overridable per use case - let's say session<br/>
<span class="error">[10/07/12 17:27:47]</span> Emmanuel Bernard: or is that it should not be settable per entity at all?<br/>
<span class="error">[10/07/12 17:28:06]</span> Sanne Grinovero: the first one. having a default on the entity sounds reasonable.<br/>
<span class="error">[10/07/12 17:28:18]</span> Emmanuel Bernard: or are you just fooling around to make my headache bigger <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 17:28:35]</span> Emmanuel Bernard: I agree with that<br/>
<span class="error">[10/07/12 17:28:42]</span> Emmanuel Bernard: it should be overridable<br/>
<span class="error">[10/07/12 17:28:49]</span> Sanne Grinovero: But having override capabilities casts a shade on complexity in API, that's why I'm rasing a warning flag now<br/>
<span class="error">[10/07/12 17:28:52]</span> Emmanuel Bernard: but before it's overridable, it should be settable<br/>
<span class="error">[10/07/12 17:28:55]</span> Sanne Grinovero: as I'm not sure how that would look like<br/>
<span class="error">[10/07/12 17:29:33]</span> Sanne Grinovero: Ok let's get back on the "how to set options" then? I mean generally, where quorum is just an example.<br/>
<span class="error">[10/07/12 17:30:08]</span> Sanne Grinovero: Where you thinking about a single annotation to handle all special features of each NoSQL implementation?<br/>
<span class="error">[10/07/12 17:30:47]</span> Emmanuel Bernard: No I was thinking of one annotation per feature<br/>
<span class="error">[10/07/12 17:31:08]</span> Emmanuel Bernard: @EmbedAssociationIdsInDocument for example<br/>
<span class="error">[10/07/12 17:31:35]</span> Sanne Grinovero: Haa nice.<br/>
<span class="error">[10/07/12 17:31:36]</span> Emmanuel Bernard: This annotation might or might not have to be annotated @OGMMetadata<br/>
<span class="error">[10/07/12 17:31:42]</span> Emmanuel Bernard: which was the question I had<br/>
<span class="error">[10/07/12 17:32:23]</span> Sanne Grinovero: Ok but what's the point of @OGMMetadata(for=MongoDBDatastoreProvider.class) ?<br/>
<span class="error">[10/07/12 17:32:53]</span> Sanne Grinovero: I would at least change that to @OGMMetadata(for=DataStoreTypes.KEY_VALUE_STORES)<br/>
<span class="error">[10/07/12 17:33:28]</span> Emmanuel Bernard: I see two benefits:</p>
<ul class="alternate" type="square">
<li>separate in the doc generic settings from provider specific settings</li>
<li>possibly filter out metadata passed to the dialect<br/>
<span class="error">[10/07/12 17:33:35]</span> Sanne Grinovero: so that people can for example extend MongoDBDatastoreProvider<br/>
<span class="error">[10/07/12 17:33:36]</span> Emmanuel Bernard: the second point it not that important<br/>
<span class="error">[10/07/12 17:34:26]</span> Emmanuel Bernard: So you're against specialization, at least for now<br/>
<span class="error">[10/07/12 17:34:26]</span> Sanne Grinovero: +1<br/>
<span class="error">[10/07/12 17:34:35]</span> Emmanuel Bernard: which is fine by me<br/>
<span class="error">[10/07/12 17:35:03]</span> Sanne Grinovero: Well I still hope to plugin Redis inheriting most of the work done for Mongo, for example..<br/>
<span class="error">[10/07/12 17:35:26]</span> Sanne Grinovero: (well bad example as they are different.. let's say CouchDB v Mongo)<br/>
<span class="error">[10/07/12 17:36:04]</span> Emmanuel Bernard: yes in_entity and such will be inherited<br/>
<span class="error">[10/07/12 17:36:12]</span> Emmanuel Bernard: as they are conceptual settings<br/>
<span class="error">[10/07/12 17:36:26]</span> Emmanuel Bernard: the quorum to a great extend is also a conceptual setting<br/>
<span class="error">[10/07/12 17:36:41]</span> Emmanuel Bernard: unsafe is specific to mongodb though<br/>
<span class="error">[10/07/12 17:37:23]</span> 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?<br/>
<span class="error">[10/07/12 17:37:48]</span> Sanne Grinovero: so "HasUnsafeOptions" would be an interface implemented by the MongoDBDatastoreProvider, and you point to that.<br/>
<span class="error">[10/07/12 17:37:55]</span> Sanne Grinovero: (to that interface)<br/>
<span class="error">[10/07/12 17:38:42]</span> Sanne Grinovero: so then we can have "MapReduceCapable" & "JSONCapable" kind of datastores, and one mixed interfaces as markers on new datastores.<br/>
<span class="error">[10/07/12 17:38:55]</span> Sanne Grinovero: s/mixed/mixes<br/>
<span class="error">[10/07/12 17:40:00]</span> Emmanuel Bernard: hum, I see, I'm a bit concerned about the complexity we put down the dialect<br/>
<span class="error">[10/07/12 17:40:07]</span> Emmanuel Bernard: but I guess that's inevitable<br/>
<span class="error">[10/07/12 17:40:21]</span> Emmanuel Bernard: I ahve to admit I thought they would be simpler than they are today<br/>
<span class="error">[10/07/12 17:40:49]</span> Sanne Grinovero: Alternatively, WDYT about the enum for the options? We still need to maintain somewhere which datastores are triggered by each enum.<br/>
<span class="error">[10/07/12 17:41:34]</span> Sanne Grinovero: I mean a function "@OGMMetadata(for=DataStoreTypes.KEY_VALUE_STORES) matched MonDBDatastoreProvider ?"<br/>
<span class="error">[10/07/12 17:41:44]</span> Sanne Grinovero: which somehow needs to deal with custom extensions of it.<br/>
<span class="error">[10/07/12 17:42:55]</span> Emmanuel Bernard: PS mongodb is not key/value store <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 17:43:25]</span> Sanne Grinovero: ok that function returns "false", but we still need to implement the function..<br/>
<span class="error">[10/07/12 17:43:27]</span> Emmanuel Bernard: And you would have the provider list the enums it is sensitive to?<br/>
<span class="error">[10/07/12 17:44:16]</span> Sanne Grinovero: that might be a good idea. Otherwise one goes with the marker interfaces rather than enums.<br/>
<span class="error">[10/07/12 17:44:54]</span> Emmanuel Bernard: The problem I see with enum is that it will be polluted very quickly with tons of provier specific options<br/>
<span class="error">[10/07/12 17:46:16]</span> 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.<br/>
<span class="error">[10/07/12 17:46:20]</span> Emmanuel Bernard: hum hold on, I am mixing the annotation describing the feature and this for options<br/>
<span class="error">[10/07/12 17:47:00]</span> 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.<br/>
<span class="error">[10/07/12 17:47:22]</span> Sanne Grinovero: hold on, a Visitor does the trick.<br/>
<span class="error">[10/07/12 17:48:12]</span> Sanne Grinovero: @OGMMetadata(appliesOn=CustomVisitableImplementor.class)<br/>
<span class="error">[10/07/12 17:49:09]</span> 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)<br/>
<span class="error">[10/07/12 17:50:29]</span> Emmanuel Bernard: What does this CustomVisitableImplementor.class look like?<br/>
<span class="error">[10/07/12 17:51:59]</span> Sanne Grinovero: should have a single method like "void accept(DataStoreCapabilities dsc, Annotation a) { dsc.accept( this, a ); }<br/>
<span class="error">[10/07/12 17:52:15]</span> Sanne Grinovero: sorry the second "accept" should be "visit"<br/>
<span class="error">[10/07/12 17:52:56]</span> Emmanuel Bernard: what does the .visit method do?<br/>
<span class="error">[10/07/12 17:53:23]</span> Sanne Grinovero: this gets forced by an interface let's say "OptionsAcceptsVisitor"<br/>
<span class="error">[10/07/12 17:53:29]</span> Sanne Grinovero: so that visit looks like:<br/>
<span class="error">[10/07/12 17:54:17]</span> Sanne Grinovero: visit( OptionsAcceptsVisitor, Annotation a) { //this code is in the DataStore itself, so it can tell you if it supports a or not}<br/>
<span class="error">[10/07/12 17:54:29]</span> Sanne Grinovero: The beauty lies in the fact that the visit could enforce the type<br/>
<span class="error">[10/07/12 17:54:37]</span> Sanne Grinovero: so it could be:<br/>
<span class="error">[10/07/12 17:55:07]</span> Sanne Grinovero: visit( SafeOptionAcceptsVisitor, Annotation a) { return true; }<br/>
<span class="error">[10/07/12 17:56:01]</span> Sanne Grinovero: as the accept method passes "this", so narrowing its type if the DataStoreCapabilities interface defines it.<br/>
<span class="error">[10/07/12 17:56:08]</span> Sanne Grinovero: We would then define it for most common options.<br/>
<span class="error">[10/07/12 17:56:25]</span> Sanne Grinovero: The less common options will have to read Annotation and switch on it.<br/>
<span class="error">[10/07/12 17:57:31]</span> Emmanuel Bernard: How would that be different than<br/>
<br/>
class MyNoSQLDatastoreProvider {<br/>
List<? extends Annotation> acceptedOptions() {
List<? extends Annotation> options = new ArrayList<>();
options.add(Unsafe.class);
options.add(Quorum.class);
return options
}<br/>
}<br/>
<span class="error">[10/07/12 17:59:29]</span> Emmanuel Bernard: Also what would we do if that visit true / false knowledge?<br/>
<span class="error">[10/07/12 17:59:58]</span> 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)<br/>
<span class="error">[10/07/12 18:00:36]</span> 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.<br/>
<span class="error">[10/07/12 18:00:52]</span> Sanne Grinovero: line { dsc.accept( this, a ); } should have been<br/>
<span class="error">[10/07/12 18:00:57]</span> Sanne Grinovero: { return dsc.accept( this, a ); }<br/>
<span class="error">[10/07/12 18:02:40]</span> 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.<br/>
<span class="error">[10/07/12 18:04:20]</span> 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.<br/>
<span class="error">[10/07/12 18:05:56]</span> Emmanuel Bernard: My head is still foggy but I think you lost me<br/>
<span class="error">[10/07/12 18:06:27]</span> Emmanuel Bernard: if it's compile time check, I can see the benefit even thugh that might be a bit too far<br/>
<span class="error">[10/07/12 18:06:43]</span> Emmanuel Bernard: If it's not compile time checked, then why build such a complex system<br/>
<span class="error">[10/07/12 18:07:20]</span> Emmanuel Bernard: Because in the end, the knowledge that a provider accept a given setting is only useful as a documentation for the user<br/>
<span class="error">[10/07/12 18:07:31]</span> Emmanuel Bernard: OGM does nto really care<br/>
<span class="error">[10/07/12 18:07:42]</span> Emmanuel Bernard: and won't raise an exception<br/>
<span class="error">[10/07/12 18:08:11]</span> Sanne Grinovero: Ok but that's a weakness too. if it's just untested documentation, how will you know it's correct?<br/>
<span class="error">[10/07/12 18:08:13]</span> Emmanuel Bernard: as it would limit what you could do to move from one provider to another witht he same codebase<br/>
<span class="error">[10/07/12 18:08:15]</span> Sanne Grinovero: (up to date)<br/>
<span class="error">[10/07/12 18:08:47]</span> Sanne Grinovero: I was assuming it could affect some decision in ogm-core too<br/>
<span class="error">[10/07/12 18:09:01]</span> 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<br/>
<span class="error">[10/07/12 18:09:09]</span> Emmanuel Bernard: but even that can be worked around<br/>
<span class="error">[10/07/12 18:09:25]</span> Emmanuel Bernard: if a provider decides to answer yes but lies <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:09:36]</span> Sanne Grinovero: right<br/>
<span class="error">[10/07/12 18:10:04]</span> Emmanuel Bernard: More simple could be</li>
</ul>
<p>class MyNoSQLDSP implement DSP {<br/>
CommonOptions getValidOptions {<br/>
return new MyNoSQLCommonOptions implements CommonOptions {<br/>
boolean acceptUnsafe() {return true;}<br/>
boolean acceptQuorum( return true;}<br/>
}<br/>
}<br/>
}<br/>
<span class="error">[10/07/12 18:10:18]</span> Sanne Grinovero: It would be of marginal use as when you create one it won't compile until you answered the mandatory questions <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:10:33]</span> Sanne Grinovero: +1 that looks nice and effective<br/>
<span class="error">[10/07/12 18:10:37]</span> Emmanuel Bernard: well<br/>
class MyNoSQLDSP implement DSP {<br/>
CommonOptions getValidOptions {<br/>
return new MyNoSQLCommonOptions implements CommonOptions {<br/>
boolean accept(Unsafe ann) {return true;}<br/>
boolean accept(Quorum ann) { return true;}<br/>
}<br/>
}<br/>
}<br/>
<span class="error">[10/07/12 18:11:31]</span> Sanne Grinovero: second one is using the visitor thing I just described.. so which one are you considering?<br/>
<span class="error">[10/07/12 18:11:59]</span> Sanne Grinovero: First one looks good to me too, might not read all annotation options but I guess that's not the point.<br/>
<span class="error">[10/07/12 18:12:19]</span> 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<br/>
<span class="error">[10/07/12 18:13:03]</span> 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<br/>
<span class="error">[10/07/12 18:13:37]</span> 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.<br/>
<span class="error">[10/07/12 18:13:39]</span> Emmanuel Bernard: also I despise overloading<br/>
<span class="error">[10/07/12 18:14:21]</span> Sanne Grinovero: I didn't understand " we won't pass the actual annotations put on the entities to them" .. why not?<br/>
<span class="error">[10/07/12 18:14:24]</span> 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<br/>
<span class="error">[10/07/12 18:14:43]</span> Emmanuel Bernard: unless it manually temporarily removes the generic accept(OBject) impl<br/>
<span class="error">[10/07/12 18:15:01]</span> Sanne Grinovero: I know that defeats compile time check, but you still have a nice typesafe Annotation to read.<br/>
<span class="error">[10/07/12 18:15:13]</span> Sanne Grinovero: (when you support it)<br/>
<span class="error">[10/07/12 18:15:30]</span> Sanne Grinovero: Imho it boils down to this question:<br/>
<span class="error">[10/07/12 18:15:41]</span> Sanne Grinovero: do you want all datastores to break when adding a new option?<br/>
<span class="error">[10/07/12 18:15:46]</span> 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?<br/>
<span class="error">[10/07/12 18:16:57]</span> Sanne Grinovero: don't think it matters much. Even 2000 would be very quick, sub nanosecond.<br/>
<span class="error">[10/07/12 18:17:23]</span> Emmanuel Bernard: Well it would require us to walk through all the entity metamodel and run these visits<br/>
<span class="error">[10/07/12 18:17:30]</span> Emmanuel Bernard: For no practical reason<br/>
<span class="error">[10/07/12 18:18:11]</span> Sanne Grinovero: but a visitor optimises extremely well, it basically is a constant. doesn't concern me untile I see otherwise <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:18:53]</span> Sanne Grinovero: and this is only run at startup right?<br/>
<span class="error">[10/07/12 18:18:57]</span> Emmanuel Bernard: Actually I'm wrong, it's the difference between never calling it and calling it 2000 times<br/>
<span class="error">[10/07/12 18:19:05]</span> Emmanuel Bernard: The runtime does not care about the result<br/>
<span class="error">[10/07/12 18:19:26]</span> Emmanuel Bernard: Tools might<br/>
<span class="error">[10/07/12 18:19:47]</span> Emmanuel Bernard: or some annotation processor like tools might want to get this knowledge<br/>
<span class="error">[10/07/12 18:19:51]</span> Emmanuel Bernard: and call these methods<br/>
<span class="error">[10/07/12 18:20:12]</span> Sanne Grinovero: Worst case the invoker can cache this, but I think a CHM would be slower than invoking it again.<br/>
<span class="error">[10/07/12 18:20:29]</span> Emmanuel Bernard: why do you want the result Sanne?<br/>
<span class="error">[10/07/12 18:21:03]</span> Sanne Grinovero: to say yes/no this datastore support UNSAFE ?<br/>
<span class="error">[10/07/12 18:21:44]</span> Emmanuel Bernard: In which use case do you want do ask that question?<br/>
<span class="error">[10/07/12 18:22:17]</span> Sanne Grinovero: UNSAFE is the wrong example. let's say Map/Reduce vs. Native Joins? Transactions?<br/>
<span class="error">[10/07/12 18:23:54]</span> Emmanuel Bernard: I see, not sure these should be driven by annotations<br/>
<span class="error">[10/07/12 18:24:10]</span> Emmanuel Bernard: as they are intrinsic capabilities of the provider<br/>
<span class="error">[10/07/12 18:24:17]</span> Sanne Grinovero: ah right.<br/>
<span class="error">[10/07/12 18:24:45]</span> Sanne Grinovero: @EmbedAssociationIdsInDocument ?<br/>
<span class="error">[10/07/12 18:25:06]</span> Sanne Grinovero: I (guess) some datastores won't be able to do that..<br/>
<span class="error">[10/07/12 18:25:39]</span> Emmanuel Bernard: well some datastores might decide not to support hat because that's meaningless for them<br/>
<span class="error">[10/07/12 18:25:43]</span> Emmanuel Bernard: liek Infinispan<br/>
<span class="error">[10/07/12 18:26:03]</span> Emmanuel Bernard: until we have inplace load / append<br/>
<span class="error">[10/07/12 18:26:19]</span> Sanne Grinovero: isn't that what started this discussion ?<br/>
<span class="error">[10/07/12 18:27:23]</span> 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<br/>
<span class="error">[10/07/12 18:27:50]</span> Emmanuel Bernard: I think<br/>
<span class="error">[10/07/12 18:27:53]</span> Emmanuel Bernard: <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:28:14]</span> Sanne Grinovero: So you want to annotate the @EmbedAssociationIdsInDocument with some meta-annotation to document it only?<br/>
<span class="error">[10/07/12 18:28:33]</span> Emmanuel Bernard: to filter it<br/>
<span class="error">[10/07/12 18:28:36]</span> Sanne Grinovero: I assumed it would affect runtime of ogm-core too<br/>
<span class="error">[10/07/12 18:29:03]</span> Emmanuel Bernard: We won't pass / stock all annotations to our metadata provider service<br/>
<span class="error">[10/07/12 18:29:25]</span> Sanne Grinovero: why not?<br/>
<span class="error">[10/07/12 18:29:31]</span> Emmanuel Bernard: and we cna't read them all the time because of the nasty synchronize in the vm<br/>
<span class="error">[10/07/12 18:30:14]</span> 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?<br/>
<span class="error">[10/07/12 18:30:45]</span> Sanne Grinovero: I'm confused about what the Infinispan datastore is going to deal with a @EmbedAssociationIdsInDocument annotated collection?<br/>
<span class="error">[10/07/12 18:30:53]</span> Sanne Grinovero: s/what/how<br/>
<span class="error">[10/07/12 18:30:59]</span> Emmanuel Bernard: I guess memory wise that would boil down to the pointers pointing to the annotations<br/>
<span class="error">[10/07/12 18:31:09]</span> Emmanuel Bernard: plus the structure storing them<br/>
<span class="error">[10/07/12 18:31:40]</span> Sanne Grinovero: maybe, but Hardy is rewriting it all via Jandex anyway.<br/>
<span class="error">[10/07/12 18:31:52]</span> Emmanuel Bernard: and?<br/>
<span class="error">[10/07/12 18:32:05]</span> Emmanuel Bernard: Jandex magically store them in thin air? <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:32:35]</span> Sanne Grinovero: no, exactly my point: they are going to be read anyway as that's out of our control<br/>
<span class="error">[10/07/12 18:33:04]</span> 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<br/>
<span class="error">[10/07/12 18:35:21]</span> Emmanuel Bernard: <a href="https://github.com/jbossas/jandex/blob/master/src/test/java/org/jboss/jandex/test/BasicTestCase.java">https://github.com/jbossas/jandex/blob/master/src/test/java/org/jboss/jandex/test/BasicTestCase.java</a><br/>
<span class="error">[10/07/12 18:35:39]</span> Emmanuel Bernard: not exactly a typesafe and friendly API <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:38:17]</span> Sanne Grinovero: Cool they finally merged my patches in ANTLR 3.4.x<br/>
<span class="error">[10/07/12 18:38:34]</span> Sanne Grinovero: getting me some hope <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:46:28]</span> Emmanuel Bernard: With ORM using Jandex are we going to force the user to add a build time phase to build the jandex index?<br/>
<span class="error">[10/07/12 18:46:38]</span> Emmanuel Bernard: or are wegoing to build it at runtime<br/>
<span class="error">[10/07/12 18:46:39]</span> Emmanuel Bernard: ?<br/>
<span class="error">[10/07/12 18:47:10]</span> 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.<br/>
<span class="error">[10/07/12 18:47:50]</span> Sanne Grinovero: hopefully the runtime-built index will get reused in next bootup..<br/>
<span class="error">[10/07/12 18:52:05]</span> Sanne Grinovero: ANTLR/master doesn't even compile <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/sad.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:52:16]</span> Nicolas Helleringer: :s<br/>
<span class="error">[10/07/12 18:52:31]</span> Emmanuel Bernard: hey it's run by the same guys who maintain the Infinispan test suite ;P<br/>
<span class="error">[10/07/12 18:52:45]</span> Sanne Grinovero: me <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/biggrin.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10/07/12 18:53:06]</span> Sanne Grinovero: I think I'm the only one contributing to both (devil)<br/>
<span class="error">[10/07/12 18:55:09]</span> Emmanuel Bernard: I think I'll need a chat with Hardy on Jandex tomorrow<br/>
<span class="error">[10/07/12 18:56:20]</span> 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.<br/>
<span class="error">[10/07/12 18:56:36]</span> Emmanuel Bernard: Not sure if they add a typesafe facade in front of it<br/>
<span class="error">[10/07/12 18:56:52]</span> Emmanuel Bernard: or if they will suffer big time when maintaining Hibernate OGM down the road<br/>
<span class="error">[10/07/12 18:59:28]</span> 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.</p></div>
<div style="color:#505050;padding:4px 0 0 0;"> </div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td><!-- End #email-page -->
</tr>
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
This message is automatically generated by JIRA.<br />
If you think it was sent incorrectly, please contact your <a style='color:#6c797f;' href='https://hibernate.onjira.com/secure/ContactAdministrators!default.jspa'>JIRA administrators</a>.<br />
For more information on JIRA, see: <a style='color:#6c797f;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
</td>
</tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->