[Yanel-dev] [Yarep] Transient storage

[Balz Schreier]

Hi Michael,

as you probably noticed, I am a big fan of Specs (*JSRs*) 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.

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):

So when thinking about your mail, I'd like to share two opinions:

1) *Persistence*: As you outlined, Yarep saves the node as well as indexes
the node for each call of a Setter.
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.

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.

When looking at the *JPA* (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.
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).
but if you *DETACH* it prior to modifying properties, all changes are only
saved in that POJO and not in the persistence store, nor in the index.
if you *ATTACH* it again, you can save the full bean (flush to the store)
and have it implicitly indexed too.

So I think that this approach would be a nice add-on for Yarep.

The advantage of this approach:
- fully backwards compatible with Yarep's current impl (default: set -->
save, index)
- the application's business logic has full control of how data changes
should be persisted

2) *Indexing*:
I could imagine that something similar here would be nice too.
Let the application's business logic decide, whether the bean changes should
get indexed or not.
node.detach();
node.setX();
node.setY();
...
if (we should not yet index the doc, but save it) {
  node.skipIndexing();
}
node.save(); // I think a method called attach() is not necessary. save()
could just flush the whole bean to the store.


Cheers
Balz

On Tue, Mar 22, 2011 at 12:09 PM, Michael Wechner <michael.wechner at wyona.com
> wrote:

> On 3/22/11 11:44 AM, Michael Wechner wrote:
>
>> Hi
>>
>> In the case of JCR the API "suggests" to implement a transient storage,
>> e.g.
>>
>> node.setProperty("author", "alice");
>> node.refresh();
>> node.setProperty("author", "bob");
>> session.save();
>>
>> which means only "author:bob" is saved persistently (whereas
>> "author:alice" was just in memory, or/and maybe swapped temporarily). Also
>> see
>>
>> http://wiki.apache.org/jackrabbit/ExamplesPage#Versioning_Basics
>>
>> http://www.day.com/specs/jcr/1.0/4.1.3.2_Transient_Storage_in_the_Session.html
>>
>> In Yarep one does not have this possibility to different between transient
>> and persistent, but
>> I think it would make sense in certain cases, e.g.
>>
>> - Guarantee atomic changes
>> - Peformance, e.g. document parsing for Lucene (let's say 1000 properties
>> are set per node and parse once instead a 1000 times)
>>
>
> Re indexing it came to my mind that we could make the explicite/implicite
> indexing configurable within the search-config, e.g.
>
> <s:search-index on-persistence="false" ...
>
> whereas default would be true in order to stay backwards compatible, but if
> set to false, then one
> could call the indexer explicitely
>
> node.setProperty("author", "alice");
> ....
> repository.getIndexer().index(node);
>
>
>
>> We could introduce additional methods, e.g.
>>
>> boolean transient = true;
>> node.setProperty("author", "alice", transient);
>> node.save();
>>
>> whereas in order to make it backwards compatible one could introduce this
>> as a versioned interface.
>>
>
> Balz just pointed out to me
>
> http://openejb.apache.org/3.0/jpa-concepts.html
>
> which might also give some good ideas.
>
> Thanks
>
> Michael
>
>
>> WDYT?
>>
>> Thanks
>>
>> Michael
>>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20110322/4641da30/attachment.html>