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
