wow! What a healthy discussion I've fired! :-) My use of DAO (as in DATA Access Object) is to abstract the (granted, small, *but* only when you've got used to it) complexities of JCR API to to-be users of my storage (store, retrieve, findByXXX, etc.) classes while controlling the properties the nt:unstructured nodes of my system can have.
It's not (at least in my case) used as a DB replacement, nor with any OCM tools, just a plain store(FilePlusMetadata myObject) kind of thing, where FilePlusMetadata has both the file to store and the properties I want to store about it, there's no room for a potential developer (re)using storage to be able to store other properties appart from the ones I'm interested into. I also think that JCR is suited as an OCM solution... or else don't just ask to add another rule to David's Model, ask also to remove the OCM-related packages/API (please don't! I'm sure many users use 'em ;)) Thanks On Mon, Nov 16, 2009 at 6:15 PM, Bertrand Delacretaz <[email protected]> wrote: > Hi Ard, > > On Mon, Nov 16, 2009 at 2:39 PM, Ard Schrijvers > <[email protected]> wrote: >> ...Just wondering: where does jackrabbit-ocm fit in then? I do not have >> that much experience with it, but it feels like JCR-to-object to me. >> Only use it when your really really have to :-)))?... > > Actually...yes and no. > > After rereading this thread I'd say something like "if you're coming > from a relational world where object-to-DB mapping is the norm, think > twice before using it in the JCR world. You might not need it, as the > JCR API is much closer to what you need at the content application > level". > > -Bertrand > -- Fabián Mandelbaum IS Engineer
