jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: Removing Items
Date Wed, 15 Aug 2007 20:29:48 GMT
> 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.

No need to goto extremes now. Please try and remember the perspective that I
at looking at it and what I said I was comparing against (an sql database
and the JDBC API).

> 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.

Because of the dynamic nature of changes that are occurring within our
application at runtime.

> 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.

How ironic ;)

> 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
> system.
Fair enough. However, look at it from the reverse point of view, what would
the impact to the users of the API be if setting a property to null DIDN'T
remove it (assuming there was a flag that could be set to toggle the
behavior on startup to deal with compatibility issues)? The existing
remove() function would then be used to remove properties when not desired,
instead of setting properties to null and having this side-effect. I believe
that the API would be more intuitive to most, if not all users, the
workarounds that we have developed wouldn't be required, and that nobody
would be raising any issues about the loss of meta data information from a
node (which you never commented on, btw. I'm really having a difficult time
seeing this loss of the node name and the node type as being a positive
thing, except maybe from an implementation perspective?).



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message