[jr3] Node types

[Thomas Müller <th...@day.com>]

Currently node types are integral part of the repository. There is a
special storage mechanism (the file custom_nodetypes.xml), which is
non-transactional and problematic for clustering.

To simplify the architecture ('microkernel'), could the node type
functionality be implemented outside the kernel, as some kind of
observation listeners? The node type configuration could be stored as
regular nodes in s special tree. When registering or modifying a node
type, existing nodes may have to be updated of course. The node type
information itself could be stored in the nodes itself as a hidden
property.

Re: [jr3] Node types

[Marcel Reutegger <ma...@gmx.net>]

On Fri, Feb 19, 2010 at 17:05, Jukka Zitting <ju...@gmail.com> wrote:
> I'd make node type constraints and security checks the responsibility
> of the client who commits the transaction.

+1

I think these are high level functions that do not belong into the micro-kernel.

regards
 marcel

Re: [jr3] Node types

[Alexander Klimetschek <ak...@day.com>]

On Fri, Feb 19, 2010 at 16:41, Jukka Zitting <ju...@gmail.com> wrote:
> I'd go even further and drop the callback mechanism. Instead just have
> a method like
>
>    TransactionId getLatestTransaction()
>
> in the persistence layer and have higher level code poll (for
> observation listeners, etc.) or explicitly request (for
> Repository.login, Session.refresh and Session.save) the latest state
> of the repository.

Hmm, but how to make sure to not miss anything in case of concurrent
threads? (Maybe I am missing something here, so excuse my question).

On Fri, Feb 19, 2010 at 17:05, Jukka Zitting <ju...@gmail.com> wrote:
> I'd make node type constraints and security checks the responsibility
> of the client who commits the transaction. I don't see the point of
> doing such steps after the transaction has already been committed.

+1

Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Node types

[Alexander Klimetschek <ak...@day.com>]

On Fri, Feb 19, 2010 at 17:30, Thomas Müller <th...@day.com> wrote:
>> I'd make node type constraints and security checks the responsibility
>> of the client who commits the transaction.
>
> That's a solution :-) I'm not sure it's the _right_ solution, but we
> can start like that.

At its heart I see JCR as an unstructured data storage. Node types are
just an "add-on". So the core/micro-kernel should work fast and scale
well with pure unstructured nodes & properties.

It doesn't have to care about types, which leads to simpler code, and
the kernel shouldn't be optimized for them; since it always has to
support unstructured data, it cannot use constrained types to optimize
the underlying data storage anyway. For example creating fixed-sized
columns in a RDBMS. (Well, it could do that selectively, but that
would lead to an enormous complexity).

So all type checking should happen at the higher level. This is also
good if you want to do imports that "violate" JCR level constraints
(such as system props and versioning) - you get it for free at the
lower layer (except for the data format, but this is another topic).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Node types

[Thomas Müller <th...@day.com>]

Hi,

> I don't see the point of doing such steps after the transaction has already been committed.

Well, because you don't have a callback mechanism that gets called
_before_ committing (or reading, in the case of security).

> I'd make node type constraints and security checks the responsibility
> of the client who commits the transaction.

That's a solution :-) I'm not sure it's the _right_ solution, but we
can start like that.

Regards,
Thomas

Re: [jr3] Node types

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Feb 19, 2010 at 5:00 PM, Thomas Müller <th...@day.com> wrote:
> This would be after the fact and wouldn't work to validate that
> changes are correct (to verify added / changed nodes don't violate
> node type constraints). Also it wouldn't work for security.

I'd make node type constraints and security checks the responsibility
of the client who commits the transaction. I don't see the point of
doing such steps after the transaction has already been committed.

BR,

Jukka Zitting

Re: [jr3] Node types

[Thomas Müller <th...@day.com>]

Hi,

This would be after the fact and wouldn't work to validate that
changes are correct (to verify added / changed nodes don't violate
node type constraints). Also it wouldn't work for security.

Regards,
Thomas

Re: [jr3] Node types

[Marcel Reutegger <ma...@gmx.net>]

hi,

hmm, why not... sounds much simpler and the polling shouldn't be too expensive.

regards
 marcel

On Fri, Feb 19, 2010 at 16:41, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 4:30 PM, Marcel Reutegger
> <ma...@gmx.net> wrote:
>> I think we wouldn't even have to restrict the callback to a single
>> object, but just keep it simple.
>>
>> something like that
>>
>> public void transactionCommitted(TransactionId id);
>>
>> given the mvcc support of the micro-kernel, a listener could then
>> re-construct the changes to the previous transaction using regular
>> micro-kernel read API.
>
> I'd go even further and drop the callback mechanism. Instead just have
> a method like
>
>    TransactionId getLatestTransaction()
>
> in the persistence layer and have higher level code poll (for
> observation listeners, etc.) or explicitly request (for
> Repository.login, Session.refresh and Session.save) the latest state
> of the repository.
>
> BR,
>
> Jukka Zitting
>

Re: [jr3] Node types

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Feb 19, 2010 at 4:30 PM, Marcel Reutegger
<ma...@gmx.net> wrote:
> I think we wouldn't even have to restrict the callback to a single
> object, but just keep it simple.
>
> something like that
>
> public void transactionCommitted(TransactionId id);
>
> given the mvcc support of the micro-kernel, a listener could then
> re-construct the changes to the previous transaction using regular
> micro-kernel read API.

I'd go even further and drop the callback mechanism. Instead just have
a method like

    TransactionId getLatestTransaction()

in the persistence layer and have higher level code poll (for
observation listeners, etc.) or explicitly request (for
Repository.login, Session.refresh and Session.save) the latest state
of the repository.

BR,

Jukka Zitting

Re: [jr3] Node types

[Marcel Reutegger <ma...@gmx.net>]

hi,

I think we wouldn't even have to restrict the callback to a single
object, but just keep it simple.

something like that

public void transactionCommitted(TransactionId id);

given the mvcc support of the micro-kernel, a listener could then
re-construct the changes to the previous transaction using regular
micro-kernel read API.

regards
 marcel

On Fri, Feb 19, 2010 at 11:53, Thomas Müller <th...@day.com> wrote:
> Hi,
>
>> Which makes observation listeners an integral part of the microkernel, btw.
>
> The microkernel would only need to support one "callback object"
> (listener is probably the wrong word, because it is also called for
> read operations). This one would then call (and allow to register)
> regular JCR observation listeners. It would also deal with / delegate
> security, constraint checking like node type, and so on.
>
> I'm not sure who should be able to write to the node type system. It
> would be great if any session (with sufficient access rights) can,
> because that would simplify clustering. The 'node type system' would
> then just listen for changes on those nodes (and possibly revert those
> changes if they don't make sense - rolling back that transaction).
>
> Regards,
> Thomas
>

Re: [jr3] Node types

[Thomas Müller <th...@day.com>]

Hi,

> Which makes observation listeners an integral part of the microkernel, btw.

The microkernel would only need to support one "callback object"
(listener is probably the wrong word, because it is also called for
read operations). This one would then call (and allow to register)
regular JCR observation listeners. It would also deal with / delegate
security, constraint checking like node type, and so on.

I'm not sure who should be able to write to the node type system. It
would be great if any session (with sufficient access rights) can,
because that would simplify clustering. The 'node type system' would
then just listen for changes on those nodes (and possibly revert those
changes if they don't make sense - rolling back that transaction).

Regards,
Thomas

Re: [jr3] Node types

[Alexander Klimetschek <ak...@day.com>]

On Thu, Feb 18, 2010 at 09:43, Thomas Müller <th...@day.com> wrote:
> Currently node types are integral part of the repository. There is a
> special storage mechanism (the file custom_nodetypes.xml), which is
> non-transactional and problematic for clustering.
>
> To simplify the architecture ('microkernel'), could the node type
> functionality be implemented outside the kernel

+1

> as some kind of observation listeners?

The microkernel shouldn't know about nodetypes. It should treat
everything as unstructured.

The higher layer, that enforces node types would store them in a
well-known location, and access them when needed. If these need to be
cached in-memory and a cluster is used, then we need observation
listeners.

Which makes observation listeners an integral part of the microkernel, btw.

> The node type configuration could be stored as
> regular nodes in s special tree.

+1

> When registering or modifying a node
> type, existing nodes may have to be updated of course. The node type
> information itself could be stored in the nodes itself as a hidden
> property.

Isn't that the case already? A node points to its a node type
definition, and eg. if that one is not found, Jackrabbit automatically
falls back to nt:unstructured.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com