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
schema:
- 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.
Florent
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 <[EMAIL PROTECTED]> 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
