"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 implementation. Regards, Mark On 8/15/07, Thomas Mueller <[EMAIL PROTECTED]> 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 >
