[meetoblivion]

I am definitely still missing something though.

For example, the package org.jboss.dna.jcr.nodetypes is not in any output JAR file from the maven build.

In addition, RepositoryNodeTypeManager which appears to be in org.jboss.dna.jcr is default level. Is this on purpose? It doesn't appear that I can run an app based on the test case, unless I put my code in org.jboss.dna.jcr.

[rhauch]

Thanks for testing this patch out. Do you have a better suggestion for the config property?

Yes, almost everything is stored as a blog inside the database. This design was chosen as a tradeoff between a performance and complexity. For example, a more normalized and transparent schema that had separate records for each property value would require many more statements to read, create and update lots of nodes, and thus performance would suffer. Plus, there's the whole nasty issue about the DBMS datatype used to to store the property value. Are there different columns for different types? And what do we do about long strings and the different maximum VARCHAR lengths for different DBMSes? I've done designs like this in the past, and they got to be a big mess very quickly.

This design attempts to store all the properties on a node in a single blob (and optionally compressed), with the exception of 'large property values' that are instead stored in a separate table (keyed by SHA1 hash of the property value). This trades off the speed to read or change only one property for the far more common case of reading all properties more efficiently and easily. Children, on the other hand, are stored as separate records, since that makes sense for updates/insertions/deletions as well as navigation.

One major disadvantage of this design is that the content cannot be searched using property values. Instead, we will be relying upon an approach that leverages a search engine and that offers more search functionality (e.g., rankings, similarity, etc.). After all, this is much closer to what JCR exposes. We already have prototypes for this, and it will be coming in the next release.

Basically, the JPA connector is relying upon a DBMS purely for transactional storage, and the design reflects this. It also means that the data is far less transparent to other applications. Hopefully, we're somewhere close to the sweet spot for our usage.

Now, having said this, this design may not be exactly what everyone needs. For this reason, the JPA connector was designed to support different kinds of schemas (what we call "models"), though only one per database instance. So it other models can be created to better suit your needs. Or, you could always create a new connector that doesn't rely upon Hibernate. After all, JBoss DNA makes it possible to people to use the best connector(s) for each use case.

[rhauch]

"meetoblivion" wrote:
I am definitely still missing something though.

For example, the package org.jboss.dna.jcr.nodetypes is not in any output JAR file from the maven build.

Really? In my 'dna-jcr/target' directory, the dna-jcr-0.6-SNAPSHOT.jar does indeed have these classes:

inflated: org/jboss/dna/jcr/nodetype/InvalidNodeTypeDefinitionException.class
 inflated: org/jboss/dna/jcr/nodetype/NodeDefinitionTemplate.class
 inflated: org/jboss/dna/jcr/nodetype/NodeTypeDefinition.class
 inflated: org/jboss/dna/jcr/nodetype/NodeTypeExistsException.class
 inflated: org/jboss/dna/jcr/nodetype/NodeTypeTemplate.class
 inflated: org/jboss/dna/jcr/nodetype/PropertyDefinitionTemplate.class

As for

"meetoblivion" wrote:
In addition, RepositoryNodeTypeManager which appears to be in org.jboss.dna.jcr is default level. Is this on purpose? It doesn't appear that I can run an app based on the test case, unless I put my code in org.jboss.dna.jcr.

Yes, this is intensional. You should not be casting the result of "session.getWorkspace().getNodeTypeManager()" to the RepositoryNodeTypeManager (which should be packaged protected), but to the JcrNodeTypeManager (which is public). In fact, we don't even mention RepositoryNodeTypeManager, since it's purely an implementation detail.

Brian just committed a change this morning that added the "JcrNodeTypeManager.registerNodeTypes(JcrNodeTypeSource)" method. That should have been there, but was probably moved during one of this release's refactorings. I also committed a change to fix the documentation, so if you get the latest you should be able to build the reference guide:

$ cd docs/reference
$ mvn clean install

You then can open "docs/reference/target/docbook/publish/en-US/html_single/reference-guide-en.html" in your browser to see the latest and greatest.

[meetoblivion]

Yeah, it must have been an eclipse issue or something, i can see them now. AndI apologize, I put in the wrong node type manager. I get the error for JcrNodeTypeManager as not being visible. That also seems to be package level default.

[meetoblivion]

Here's the other part that makes no sense.

In the guide, you have

nodeType.setMixin(true);
nodeType.getNodeDefinitionTemplates().add(childNode);

// Add a mandatory child named "source" with a required primary type of "nt:file"
NodeDefinitionTemplate childNode = nodeTypeManager.createNodeDefinitionTemplate();
childNode.setName("source");

That code clearly looks wrong, as childNode's not defined until after it's been added. I assume it's safe to just ignore.

[rhauch]

"meetoblivion" wrote:
I get the error for JcrNodeTypeManager as not being visible. That also seems to be package level default.

Right. Sorry about that. We'll apply a fix shortly.

"meetoblivion" wrote:
Here's the other part that makes no sense.

In the guide, you have

nodeType.setMixin(true);
nodeType.getNodeDefinitionTemplates().add(childNode);

// Add a mandatory child named "source" with a required primary type of "nt:file"
NodeDefinitionTemplate childNode = nodeTypeManager.createNodeDefinitionTemplate();
childNode.setName("source");

That code clearly looks wrong, as childNode's not defined until after it's been added. I assume it's safe to just ignore.

Actually, that was something I fixed in the document this morning. Basically, I moved the "nodeType.getNodeDefinitionTemplates().add(childNode);" line:

nodeType.setMixin(true);

// Add a mandatory child named "source" with a required primary type of "nt:file"
NodeDefinitionTemplate childNode = nodeTypeManager.createNodeDefinitionTemplate();
childNode.setName("source");
nodeType.getNodeDefinitionTemplates().add(childNode);

[rhauch]

Ok, JcrNodeTypeManager should now be public.

[meetoblivion]

Haha ok. I think these are resolved then. On to the next thread (for the rest server).