Hi Michael,<div><br></div><div>as you probably noticed, I am a big fan of Specs (<b>JSRs</b>) that went into the standard java distributions (Java SE, EE or even ME). The reason is that those specs (usually a concept, design including an API) have been reviewed by so many different people with the intention to judge a spec with respect to what "the majority" most probably needs when developing an application. So what is in a spec must be "good" for some reason.</div>
<div><br></div><div>So that's why I always look at specs when I have to develop a new feature and see how they did it and in the best case, I can reuse a whole API (e.g. JAXB for mapping objects to Yarep and back):</div>
<div><br></div><div>So when thinking about your mail, I'd like to share two opinions:</div><div><br></div><div>1) <b>Persistence</b>: As you outlined, Yarep saves the node as well as indexes the node for each call of a Setter.</div>
<div>In many cases this is ok, as I think "meta data properties" (= Yarep Node Properties) are usually fully independent, so data inconsistency can not occur. </div><div><br></div><div>But if you have a requirement that forces you to have dependencies between node properties, the current API does not provide full guarantee of data consistency.</div>
<div><br></div><div>When looking at the <b>JPA</b> (Java Persistence API) which deals with persisting data POJOs to a repository (db, filesystem, etc.), the API has the notion of DETACH and ATTACH a bean from a persistence context.</div>
<div>this means: per default, your data bean (in the Yarep language this would be a Yarep Node object) is always attached, each change in the bean is persisted (and indexed).</div><div>but if you <b>DETACH</b> it prior to modifying properties, all changes are only saved in that POJO and not in the persistence store, nor in the index.</div>
<div>if you <b>ATTACH</b> it again, you can save the full bean (flush to the store) and have it implicitly indexed too.</div><div><br></div><div>So I think that this approach would be a nice add-on for Yarep.</div><div><br>
</div><div>The advantage of this approach: </div><div>- fully backwards compatible with Yarep's current impl (default: set --> save, index)</div><div>- the application's business logic has full control of how data changes should be persisted</div>
<div><br></div><div>2) <b>Indexing</b>: </div><div>I could imagine that something similar here would be nice too.</div><div>Let the application's business logic decide, whether the bean changes should get indexed or not.</div>
<div>node.detach();</div><div>node.setX();</div><div>node.setY();</div><div>...</div><div>if (we should not yet index the doc, but save it) {</div><div>  node.skipIndexing();</div><div>}</div><div>node.save(); // I think a method called attach() is not necessary. save() could just flush the whole bean to the store.</div>
<div><br></div><div><br></div><div>Cheers</div><div>Balz</div><div><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 12:09 PM, Michael Wechner <span dir="ltr"><<a href="mailto:michael.wechner@wyona.com">michael.wechner@wyona.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 3/22/11 11:44 AM, Michael Wechner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
In the case of JCR the API "suggests" to implement a transient storage, e.g.<br>
<br>
node.setProperty("author", "alice");<br>
node.refresh();<br>
node.setProperty("author", "bob");<br>
session.save();<br>
<br>
which means only "author:bob" is saved persistently (whereas "author:alice" was just in memory, or/and maybe swapped temporarily). Also see<br>
<br>
<a href="http://wiki.apache.org/jackrabbit/ExamplesPage#Versioning_Basics" target="_blank">http://wiki.apache.org/jackrabbit/ExamplesPage#Versioning_Basics</a><br>
<a href="http://www.day.com/specs/jcr/1.0/4.1.3.2_Transient_Storage_in_the_Session.html" target="_blank">http://www.day.com/specs/jcr/1.0/4.1.3.2_Transient_Storage_in_the_Session.html</a> <br>
<br>
In Yarep one does not have this possibility to different between transient and persistent, but<br>
I think it would make sense in certain cases, e.g.<br>
<br>
- Guarantee atomic changes<br>
- Peformance, e.g. document parsing for Lucene (let's say 1000 properties are set per node and parse once instead a 1000 times)<br>
</blockquote>
<br></div>
Re indexing it came to my mind that we could make the explicite/implicite indexing configurable within the search-config, e.g.<br>
<br>
<s:search-index on-persistence="false" ...<br>
<br>
whereas default would be true in order to stay backwards compatible, but if set to false, then one<br>
could call the indexer explicitely<br>
<br>
node.setProperty("author", "alice");<br>
....<br>
repository.getIndexer().index(node);<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We could introduce additional methods, e.g.<br>
<br>
boolean transient = true;<br>
node.setProperty("author", "alice", transient);<br>
node.save();<br>
<br>
whereas in order to make it backwards compatible one could introduce this as a versioned interface.<br>
</blockquote>
<br></div>
Balz just pointed out to me<br>
<br>
<a href="http://openejb.apache.org/3.0/jpa-concepts.html" target="_blank">http://openejb.apache.org/3.0/jpa-concepts.html</a><br>
<br>
which might also give some good ideas.<br>
<br>
Thanks<br><font color="#888888">
<br>
Michael</font><div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
WDYT?<br>
<br>
Thanks<br>
<br>
Michael<br>
</blockquote>
<br>
-- <br>
Yanel-development mailing list <a href="mailto:Yanel-development@wyona.com" target="_blank">Yanel-development@wyona.com</a><br>
<a href="http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development" target="_blank">http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development</a><br>
</div></div></blockquote></div><br></div>