Re: Don't do node types unless you know you're done (was: Noob questions about bundle installation.)

[John Logan]

Thanks, Felix, that completely makes sense and it does
help a lot.  I restructured my prototype to use the stock
resource types.

jgl


On Thursday, March 9, 2017 1:34 AM, Felix Meschberger  
wrote:
>    
> Hi John
> 
> Over the years of working with JCR it became clearer and 
> clearer, that JCR node types which are comparable to SQL 
> Schemas are overrated. In general you don’t need/use 
> them and can get by with nt:unstructured or 
> sling:unstructured (the difference being that  the latter 
> does not have ordered child nodes which is good for 
> performance if you don’t need it).
[snip]

Don't do node types unless you know you're done (was: Noob questions about bundle installation.)

[Felix Meschberger]

Hi John

Over the years of working with JCR it became clearer and clearer, that JCR node 
types which are comparable to SQL Schemas are overrated. In general you don’t 
need/use them and can get by with nt:unstructured or sling:unstructured (the 
difference being that the latter does not have ordered child nodes which is 
good for performance if you don’t need it).

You might also refer to rule #1 of David’s Model: 
https://wiki.apache.org/jackrabbit/DavidsModel#Rule_.231:_Data_First.2C_Structure_Later._Maybe.(David
 being David Nuescheler, JCR’s spec lead)

Why sling:resourceType ? Multiple reasons apply. One is that JCR primary node 
type basically is an XML name which has a namespace, colon, and local name 
part. This is too limiting for sling’s requirements to resolve scripts. 
Another, at the time more important reason, actually, is that JCR 1 did not 
allow to change the primary node type of a JCR node, so you could not decide on 
another „type“ of your node and thus rendition. This has been fixed in JCR 2. 
Thirdly, it was my impression, that JCR primary node type is about structure 
and schema (remember you can get by with just nt:unstructured…) while 
sling:resourceType is about processing the node during a request, hence it is 
used for rendering/presentation purposes. I think this is a different story and 
thus we use a different property.

Hope that helps

Regards
Felix

Am 09.03.2017 um 00:43 schrieb John Logan 
<john.lo...@texture.com<mailto:john.lo...@texture.com>>:

Responding to my own email to conserve anyone else's effort.
I fired off my last response before doing a cursory web search :/

It looks like, in the old old days, one way to effect a node
type change is to stop Sling, delete the custom_nodetypes.xml
file, and restart, causing the node types to be reloaded [1].
That doesn't seem to be applicable to my repo (Sling 9).

The JCR spec says I can muck about with node types if
they're unreferenced [2].  Perhaps I can perform a schema
change by:
- Changing affected nodes to the base type.
- Performing any needed migration operations
(e.g. deleting or adding node properties).
- Performing node type management operations
in the JCR (the big hammer being removing the
node type, and installing bundles with new node
type definitions)
- Changing nodes back to the custom type.

I do also see JIRA references for support of reregistration
of minor node type changes.

I certainly don't want to have to change data types,
and for now I can just populate a new repository more
easily, but since I've opened this box I'm curious to know
how it should be done.

Or, is this one reason why sling:resourceType exists?  I want
to be able to locate nodes by type efficiently, but I'm fine
with my application code ensure proper node structure.
Might it be a better approach to stick wth JCR builtin types
and use sling:resourceType for locating nodes?

John

[1] 
http://jackrabbit.510166.n4.nabble.com/Incremental-node-type-update-td518833.html
[2] 
https://docs.adobe.com/content/docs/en/spec/jcr/2.0/19_Node_Type_Management.html


From: John Logan <john.lo...@texture.com<mailto:john.lo...@texture.com>>
Sent: Wednesday, March 8, 2017 2:56 PM
To: users@sling.apache.org<mailto:users@sling.apache.org>
Subject: Re: Noob questions about bundle installation.

Thank you for the response, Stefan!

I was surprised about the behavior for 1. below and I'm positive that I have 
seen the
new code activate immediately before also.  I'll look into this further.

I'm not surprised what you describe about #2.  When you say "remove this 
definition
manually", what does that entail?  If I try to delete the node type definition 
via
the composum browser, the operation fails because the node is protected.

John

Re: Noob questions about bundle installation.

[John Logan]

Responding to my own email to conserve anyone else's effort.
I fired off my last response before doing a cursory web search :/

It looks like, in the old old days, one way to effect a node
type change is to stop Sling, delete the custom_nodetypes.xml
file, and restart, causing the node types to be reloaded [1].
That doesn't seem to be applicable to my repo (Sling 9).

The JCR spec says I can muck about with node types if
they're unreferenced [2].  Perhaps I can perform a schema
change by:
 - Changing affected nodes to the base type.
 - Performing any needed migration operations
(e.g. deleting or adding node properties).
 - Performing node type management operations
in the JCR (the big hammer being removing the
node type, and installing bundles with new node
type definitions)
- Changing nodes back to the custom type.

I do also see JIRA references for support of reregistration
of minor node type changes.

I certainly don't want to have to change data types,
and for now I can just populate a new repository more
easily, but since I've opened this box I'm curious to know
how it should be done.

Or, is this one reason why sling:resourceType exists?  I want
to be able to locate nodes by type efficiently, but I'm fine
with my application code ensure proper node structure.
Might it be a better approach to stick wth JCR builtin types
and use sling:resourceType for locating nodes?

John

[1] 
http://jackrabbit.510166.n4.nabble.com/Incremental-node-type-update-td518833.html
[2] 
https://docs.adobe.com/content/docs/en/spec/jcr/2.0/19_Node_Type_Management.html


From: John Logan <john.lo...@texture.com>
Sent: Wednesday, March 8, 2017 2:56 PM
To: users@sling.apache.org
Subject: Re: Noob questions about bundle installation.
    
Thank you for the response, Stefan!

I was surprised about the behavior for 1. below and I'm positive that I have 
seen the
new code activate immediately before also.  I'll look into this further.

I'm not surprised what you describe about #2.  When you say "remove this 
definition
manually", what does that entail?  If I try to delete the node type definition 
via
the composum browser, the operation fails because the node is protected.

John

Re: Noob questions about bundle installation.

[John Logan]

Thank you for the response, Stefan!

I was surprised about the behavior for 1. below and I'm positive that I have 
seen the
new code activate immediately before also.  I'll look into this further.

I'm not surprised what you describe about #2.  When you say "remove this 
definition
manually", what does that entail?  If I try to delete the node type definition 
via
the composum browser, the operation fails because the node is protected.

John

On Wednesday, March 8, 2017 11:56 AM Stefan Seifert  
wrote:
> >1.) Are there cases where I would need to shut down and restart Sling in
> >order for an updated version of the bundle to be functional.
> > [snip]
> 
> this is strange - the new code from the bundle should get active immediately. 
> i use this way for bundles for years
> and it always worked well.
> 
> 
> >2.) The bundle defines some custom node types in a CND file.  
> >[snip]
> >Again, is there
> >something I need to do to effect a change in a node type definition that
> >doesn't involve drastic measures?
> 
> unfortunately dynamic update of a node type already registered is not 
> supported at all in jackrabbit afaik. the only
> solution i know of in a repository where the old definition was already 
> registered is to remove this definition 
> manually before installing the  new one.

stefan

RE: Noob questions about bundle installation.

[Stefan Seifert]

>1.) Are there cases where I would need to shut down and restart Sling in
>order for an updated version of the bundle to be functional.  What I'm
>seeing today is that I make a few code changes, do a "mvn clean install
>sling:install", observe that the bundle gets installed, but when I make use
>of a servlet that the bundle provides, I get the pre-update behavior.  I
>did a cursory scan of the logs and didn't see anything unusual.  If I kill
>Sling and restart it, then the servlet behaves as expected.  Is this
>expected?  Do I need to do something special for the change to be picked
>up; for example, do I need to fiddle a version number?

this is strange - the new code from the bundle should get active immediately. i 
use this way for bundles for years and it always worked well.


>2.) The bundle defines some custom node types in a CND file.  I needed to
>change a node type to add the mix:versionable mixin, but after reinstalling
>(and I believe even restarting Sling), newly created nodes didn't have the
>mixin type.  If I installed the bundle into a brand new repository, then
>those nodes would be created with the mixin type.  Again, is there
>something I need to do to effect a change in a node type definition that
>doesn't involve drastic measures?

unfortunately dynamic update of a node type already registered is not supported 
at all in jackrabbit afaik. the only solution i know of in a repository where 
the old definition was already registered is to remove this definition manually 
before installing the new one.

stefan