Re: Jackrabbit 3: extracting same name sibling support from the core
On Tue, Feb 16, 2010 at 14:25, Thomas Müller thomas.muel...@day.com wrote: Hi, A very simple implementation of my idea: http://h2database.com/p.html#e5e5d0fa3aabc42932e6065a37b1f6a8 The method hasSameNameSibling() that is called for each remove(). If it turns out to be a performance problem we could add a hidden property in the first SNS node itself (only required there). Does anybody see any other obvious problems? a remove or reorder potentially modifies lots of existing nodes. but that's probably what you mean when you say there is a risk that certain things would get a bit slower if SNS are actually used. regards marcel Regards, Thomas
Re: Jackrabbit 3: extracting same name sibling support from the core
Hi, A very simple implementation of my idea: http://h2database.com/p.html#e5e5d0fa3aabc42932e6065a37b1f6a8 The method hasSameNameSibling() that is called for each remove(). If it turns out to be a performance problem we could add a hidden property in the first SNS node itself (only required there). Does anybody see any other obvious problems? Regards, Thomas
Re: Jackrabbit 3: extracting same name sibling support from the core
On Thu, Feb 11, 2010 at 12:54, Thomas Müller thomas.muel...@day.com wrote: After moving the SNS support, it would be something like this: 1) API layer (JCR API, SPI API) 2) SNS support code, which knows about SNS, and maps SNS node names to/from internal node names 3) Jackrabbit core, doesn't know anything about SNS (node names must be unique, [ and ] are supported within node names) My hope is that this would simplify the core, because it doesn't have to deal with SNS at all. Disadvantage: there is a risk that certain things would get a bit slower if SNS are actually used (specially if there are lots of SNS). Sounds like a good idea to me, under the assumption that SNS are not so important (because they are not a very good content model concept) and thus preferring implementation simplicity over SNS performance. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Jackrabbit 3: extracting same name sibling support from the core
On Thu, Feb 11, 2010 at 11:54 AM, Thomas Müller thomas.muel...@day.com wrote: About SNS (same name siblings): what about moving that part away from the core? Currently, the Jackrabbit architecture is (simplified): 1) API layer (JCR API, SPI API) 2) Jackrabbit core, which knows about SNS After moving the SNS support, it would be something like this: 1) API layer (JCR API, SPI API) 2) SNS support code, which knows about SNS, and maps SNS node names to/from internal node names 3) Jackrabbit core, doesn't know anything about SNS (node names must be unique, [ and ] are supported within node names) My hope is that this would simplify the core, because it doesn't have to deal with SNS at all. Disadvantage: there is a risk that certain things would get a bit slower if SNS are actually used (specially if there are lots of SNS). Is this could be an optional feature in 3.X? As JCR 2.X is out and it could raise comparability problem, right? Personally I don't like/use SNS in a navigatable content system. To be safe, I created customized node type use sameNameSiblings=false as a base for all my nodes:) -Guo
Re: Jackrabbit 3: extracting same name sibling support from the core
On Thu, Feb 11, 2010 at 12:54 PM, Thomas Müller thomas.muel...@day.com wrote: Hi, About SNS (same name siblings): what about moving that part away from the core? Currently, the Jackrabbit architecture is (simplified): 1) API layer (JCR API, SPI API) 2) Jackrabbit core, which knows about SNS After moving the SNS support, it would be something like this: 1) API layer (JCR API, SPI API) 2) SNS support code, which knows about SNS, and maps SNS node names to/from internal node names 3) Jackrabbit core, doesn't know anything about SNS (node names must be unique, [ and ] are supported within node names) interesting approach. i don't know whether it's feasable (e.g. SNS-related state would probably need to be persisted), but certainly worth more investigations... cheers stefan My hope is that this would simplify the core, because it doesn't have to deal with SNS at all. Disadvantage: there is a risk that certain things would get a bit slower if SNS are actually used (specially if there are lots of SNS). Regards, Thomas
Re: Jackrabbit 3: extracting same name sibling support from the core
Hi, Is this could be an optional feature in 3.X? As JCR 2.X is out and it could raise comparability problem, right? This change wouldn't affect the public API. SNS would still be supported as they are done now. Maybe with a few changes, but all within the JCR 2.0 specification. About compatibility: existing repositories would need to be converted in some way, that's true. One way to convert is the repository copier tool: http://wiki.apache.org/jackrabbit/BackupAndMigration Regards, Thomas
