jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peeter Piegaze" <peeter.pieg...@day.com>
Subject Re: Removing Items
Date Wed, 15 Aug 2007 16:44:08 GMT
On 8/15/07, Mark Waschkowski <mwaschkowski@gmail.com> wrote:

> Yes, you don't need null in JCR, but that is also the point. In java, null
> is supported, and JCR is not a filesystem etc., its a JAVA api. With
> databases, the Java Database api (JDBC) supports both setting of and the
> retrieving of nulls from a database, so I believe that the JCR API not
> having support for a similiar semantic is not ideal.

So all Java APIs to all data stores should support null? That's not a
good argument. It is the data store that defines the model. The API is
just one possible interface to that model. The JCR model does not
support null properties therefore the API does not.

> Workaround - the main workaround that we have done is to store the structure
> of a node separately. Then, if we need to we can map a node back to the
> structure and determine what are all the possible attributes of a particular
> node, and then go forward from there. Please note, using node types to
> specify the structure ahead of time is NOT an option.

Why not? Node types do exactly that: they store the structure of the node.

> I really find it ironic that the repo doesn't keep all the properties

As the author of the spec I can tell you that while I employed both
metaphor and simile in its construction I did not knowingly include
any irony.

> because each node is like its own little bundle of data, which includes meta
> information (the node name), data (the node value) and type information (the
> node type). By having a property be removed when its set to null, that
> little bundle of data loses critical information about what exactly defines
> itself, and, in our case, require workarounds that shouldn't be necessary.

Its only a "workaround" in the sense that you are used to one model
and now you are dealing with another. Of course you will have to "work
around" that fact when adapting your application to the new storage

Peeter Piegaze
Author: JSR 170, JSR 283

View raw message