SPI: PropertyDefinition.getRequiredType
Hi. During my regression tests with JCR2SPI and my custom SPI implementation I found a difference that may indicate a missing feature in SPI. Or not. What happens is that I have a custom node type which internally holds a potentially huge amount of property definitions, and for that reason, doesn't expose them at all; instead it reports residual properties of type UNDEFINED. In my JCR implementation, when I instantiate a Property and it's PropertyDefinition, I do look up the actual type, thus getRequiredType() does not return UNDEFINED. In JCR2SPI, this doesn't happen, as QNodeTypeDefinition doesn't have a call for that, and - similarly to other SPI aspects - JCR2SPI assumes that it has complete knowledge about the node type system. The result being that JCR2SPI's PropertyDefinition.getRequiredType() returns UNDEFINED. I'm not sure whether this is worth spending any work on, but I thought it wouldn't hurt to report it. Best regards, Julian
Re: SPI: PropertyDefinition.getRequiredType
hi sorry. i reread you mail multiple times, and i don't get your point. here is what jsr170 defines: - that PropertyDefinition.getRequiredType() may be one of STRING, BINARY, DATE, LONG, DOUBLE, NAME, PATH, REFERENCE, BOOLEAN or UNDEFINED. - If PropertyDefinition.getRequiredType() is UNDEFINED, then a Property having this definition may be of any type. - The value of a property may never be UNDEFINED. Thus, Property.getType() will never return UNDEFINED. - Node.setProperty: If the node type of this node does not indicate a specific property type, then the property type of the supplied Value object is used and if the property already exists (has previously been set) it assumes both the new value and new property type. if you want to point out, that the NodeTypeRegistry doesn't get informed about new registrations: that's a known issue (see TODO.txt) and covered by the jira issue, you created recently. regards angela
Re: SPI: PropertyDefinition.getRequiredType
Angela Schreiber schrieb: hi sorry. i reread you mail multiple times, and i don't get your point. Sorry, I'll try to do better this time. here is what jsr170 defines: - that PropertyDefinition.getRequiredType() may be one of STRING, BINARY, DATE, LONG, DOUBLE, NAME, PATH, REFERENCE, BOOLEAN or UNDEFINED. OK. - If PropertyDefinition.getRequiredType() is UNDEFINED, then a Property having this definition may be of any type. OK. - The value of a property may never be UNDEFINED. Thus, Property.getType() will never return UNDEFINED. OK. - Node.setProperty: If the node type of this node does not indicate a specific property type, then the property type of the supplied Value object is used and if the property already exists (has previously been set) it assumes both the new value and new property type. Yes. if you want to point out, that the NodeTypeRegistry doesn't get informed about new registrations: that's a known issue (see TODO.txt) and covered by the jira issue, you created recently. No, the point is that in JSR-170 it is possible that for a given node type N, the NodeType interface will only return residual property definitions (because the set of property definitions on this node type may be very large), while Property.getPropertyDefinition() will return a non-residual definition (because in this case, the property name is known in advance, so the size problem above doesn't matter). I understand this is not the case for Jackrabbit, but for other stores, it may happen. What I'm trying to understand is whether this is a hole in SPI or not. Keep in mind that there are document management systems where the set of property types really is open-ended, such as in a generic WebDAV server. Best regards, Julian
Re: SPI: PropertyDefinition.getRequiredType
Jukka Zitting schrieb: Hi, On 11/22/06, Julian Reschke [EMAIL PROTECTED] wrote: No, the point is that in JSR-170 it is possible that for a given node type N, the NodeType interface will only return residual property definitions (because the set of property definitions on this node type may be very large), while Property.getPropertyDefinition() will return a non-residual definition (because in this case, the property name is known in advance, so the size problem above doesn't matter). Are you sure this is OK? At least it breaks the following symmetry: That's what I'm trying to find out... PropertyDefinition definition = property.getDefinition(); NodeType type = definition.getDeclaringNodeType(); assert Arrays.asList(type.getDeclaredPropertyDefinitions()).contains(definition); Question here is whether that symmetry is guaranteed (maybe JSR-283 can clarify that), and whether breaking the symmetry provides any useful additional information to the client... I would return the residual node definition from Property.getDefinition() unless the underlying more specific definition has been explicitly exposed through the NodeType API. Best regards, Julian
Re: SPI: PropertyDefinition.getRequiredType
No, the point is that in JSR-170 it is possible that for a given node type N, the NodeType interface will only return residual property definitions (because the set of property definitions on this node type may be very large), while Property.getPropertyDefinition() will return a non-residual definition (because in this case, the property name is known in advance, so the size problem above doesn't matter). not quite. the set of property definitions of a nodetype is always a static set and does not vary on the set of all possible properties that can be added. i.e. it does not depend on the actual contents of a node. of course they might be dynamically generated by the repository implementation and this set could be large. but afair, jsr170 does not mention that this set can be incomplete. regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
