jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume ...@nuxeo.com>
Subject Re: Removing Items
Date Thu, 16 Aug 2007 17:13:16 GMT
Two things are possible data changes and "schema" changes.

When you have a fixed schema, like in an SQL table, in a Java bean, in 
LDAP (usually), and in JCR without '*' property names in your schema, 
then there are only two cases to consider for a given property of the 
- either you have a value compatible with the type (for instance, a string)
- or there's nothing, which may be represented as a NULL pseudo-value, 
or an exception raised when you fetch it, or its absence from the Map 
when you fetch all values -- in any case that's just "nothing".

Practically everything works like that.

Now, what the OP is doing goes further: he's modifying the schema of his 
object at runtime (by using for instance nt:unstructured or '*' property 
names). So you have a new possibility, which is "property undefined in 
the schema" or, conversely, "propery added to the schema but with no 
value specified". How that is represented in a storage space where only 
the system above is possible is left up to the implementor.

In JCR, you can implement many things, but you do it *on top* of the 
"standard" storage system described above. Trying to say "JCR storage 
model must be the one in my app" doesn't help. The JCR storage model is 
there, work with it.


Mark Waschkowski wrote:
> No, thats missing the point. The point that the OP is he doesn't want to see
> a property *removed* when a property value is set to null.
> ie. a node may have 10 properties, but when one of them is set to null, the
> node no longer has 10 properties, but 9
> As in SQL, you can't NOT have a column there, its defined ahead of time. The
> column *always* exists, regardless of the value stored in the column for a
> particular row.
> The semantic should be to set the value of a property, and the property will
> contain that value, NOT (as is currently) set the value of a property, and
> if the value happens to be a null, remove the property entirely.
> Regards,
> Mark
> On 8/13/07, Florent Guillaume <fg@nuxeo.com> wrote:
>> Thomas Mueller wrote:
>>> 2) Should JCR support nullable properties?
>> I think a better question is, "does a system have a different notions
>> for a null value and the absence of a property?".
>>> Some say yes, some no. Let's see what other systems do:
>>> * XML: No (an empty string is not null)
>> And there's no "null" attribute value.
>>> * Files: No (an empty file is not null)
>> And there's no "null" file.
>>> * HTTP: No
>>> * Properties files: No
>>> * Windows registry (if I may): No
>>> * LDAP: No? (not sure)
>> LDAP goes further, usually (but it depends on the attribute "syntax", ie
>> its content model) empty strings are disallowed. And in any case there's
>> no notion of null storage.
>>> * SQL: Yes (there is no other way to say 'the property is not set')
>> But in SQL you have a given schema for your table, and if in that schema
>> you have a 'name; column then in a row its value is either a string, or
>> NULL. You can't say "I don't want a 'name' column on that row". So for
>> SQL in a given schema there's no difference between the absence of a
>> property and a NULL.
>>> * Java Hash tables: Hashtable no, HashMap yes
>> In a HashMap there's no distinction between a null value a no value:
>>    HashMap.get(Object key)
>>     Returns the value to which the specified key is mapped in this
>> identity hash map, or null if the map contains no mapping for this key.
>> So in *ALL* systems above, there is no distinction (apart from
>> introspecting schemas -- but that's a different problem) between null
>> values and absent properties. They're two facets of the same thing.
>> And as Roy explained, that's the whole point of "null". If someone wants
>> additional semantics, then they have to use a different storage model.
>> Florent
>> --
>> Florent Guillaume, Director of R&D, Nuxeo
>> Open Source Enterprise Content Management (ECM)
>> http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

View raw message