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 Fri, 17 Aug 2007 21:02:43 GMT
"Do you understand what I mean with this?"
Yes, I do. IMO this isn't a matter of making things more complicated, its a
matter of what I perceive is a flaw with the API. Again, without nulls we
have had to do a number of workarounds that would not have been otherwise
required, and not only that but I find the behavior undesirable in the
general case.

"... JCR is a persistence layer."
That is incorrect. JCR is an API that is meant to be placed atop a huge
number of vendor implementations to allow for developers to use a standard
means of interacting with said content repository implementations be it read
only, or read/write depending on the level of conformance of the



On 8/15/07, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
> > JCR ... defines the property names (columns) for every node (record) in
> the system.
> That's an implementation issue, not a API issue. At the moment
> Jackrabbit does store the property names for each row. However other
> JCR implementations do not, and Jackrabbit could be changed as well.
> > I do have situations when I need that property
> > (regardless of the value)
> I do not. But:
> 1) There are many situations where data needs to be reviewed.  This
> could be solved by extending the JCR API like this:
> - void Property.setReviewed(String reviewer, Calendar date).
> - boolean Property.isReviewed()
> - String Property.getReviewer()
> - Calendar Property.getReviewedDate()
> 2) What about having a create date and modified date for each node?
> 3) What about storing the language for each String:
> Value ValueFactory.createValue(String value, String language);
> String Value.getLanguage();
> 4) What about supporting two type of NULL: 'Missing But Applicable'
> and 'Missing But Inapplicable' (as suggested by Dr. Codd)
> Do you understand what I mean with this?
> I think the idea of an API is to support what really is required, and
> not be too complex. About the complexity of NULL in SQL, I suggest to
> read http://en.wikipedia.org/wiki/Null_%28SQL%29
> > Comparing to SQL, if you set the value of column of a row to
> > null, the value is null, but you don't lose the column.
> Again, there is no other way in SQL to say that the data is not known
> for a column. In JCR, there is (removing the property). So JCR already
> supports NULL. No need to support it in two slightly different ways.
> > NOT at all similar to the way Java itself operates.
> Java is a programming language, JCR is a persistence layer.
> Thomas

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