[rhauch]

I did receive it but haven't had a chance to try reproducing it yet. I do have another question, however:

What version of MySQL are you using? Please be sure that you are using the appropriate Hibernate dialect for your MySQL database. For example, your configuration file said you were using "org.hibernate.dialect.MySQLInnoDBDialect", but there are several available:

• org.hibernate.dialect.MySQL5Dialect
• org.hibernate.dialect.MySQL5InnoDBDialect
• org.hibernate.dialect.MySQLDialect
• org.hibernate.dialect.MySQLInnoDBDialect
• org.hibernate.dialect.MySQLMyISAMDialect

Based upon your error, I'm guessing you're using MySQL 5.x, so I'd recommend trying the "org.hibernate.dialect.MySQL5InnoDBDialect" dialect. That was added to Hibernate quite a while back to specifically address the column sizes that I think you're running into.

[sjahan]

I'm using a Mysql 5.1.41.

I'll try with MySQL5InnoDBDialect asap, i have to re-enable my versioning code first

Thank you very much,

SJ.

[sjahan]

Just tested with MySQL5InnoDBDialect, this actually solved the issue related to schema's column's size, but it's still the same exception about the versioning when we check-in the node.

Hoping we will find a solution soon, have a very nice day.

SJ.

[sjahan]

Hi Randall,

Here are some news: i debug a little bit on my side.

I don't think (but i'm not the expert) that it's related to some DB matters (transaction engine or something).

This crashes at the moment of creating the version, saying that the parent node where to store the version isn't found. The trouble is that the "not-found" node is actually right there in my DB, and of course before it's needed in the code.

The trouble is that the search is performed on the SessionCache object, which should not be up to date with the DB, since the requested object is in the DB but not in the cache.

I'll keep debugging a little bit on my side, hoping this could be a good hint to track down this problem!

Thank you very much for your help,

SJ.

[UPDATE]:

I successfully get it working by slowly debugging the whole checkin function. So i guess one process should be in charge of refreshing the sessionCache but the versioning process it too fast , and the request is fired before the cache is ready to receive it. Is there a 'simple' way to slow down the versioning process, or better, to fasten up the cache refresh process?

Thank you very much,

SJ.

[sjahan]

Hi Randall,

Here are some news. We went ahead on the debugging and here is the conclusion of our last debug session:

Our problem is due to an encoding issue and not the cache refresh as i thougth. Actually, the cache seems to act weirdly during debug, it updates while accessed, but i guess this is only due to the debugging, anyway, that's not the point.

So my version node is correctly created in the DB, no doubt about it, but there is nothing in the cache, so Modeshape goes for it. This goes well until the GraphSession's getChild method. On line 2819, this calls some ValueIterator from LinkedListMultimap and here is the trouble: the LinkedListMultimap contains two hashmaps, and Modeshape looks for the versionNode in one of these hashmaps (line 732). The versionNode is actually IN the hashmaps, but the get() returns null and this is because of the key/node name which is like this: 2011-06-28T140501.815+0200

As you can see, the three special chars are quite embarassing since i cannot event read them as i'm typing. And it seems there are not written as they are read, which is why Modeshape tells the node is not found, because of the hasmap's key isn't the same between the put() and the get().

Is there a way to solve it besides changing the version's names? Could it be related to our DB so that we could switch the encoding of our mysql DB?

I set the autoGenerateSchema option to create, and by default the tables generated are in latin_general_ci, is it normal? Is there a way to get this working besides waiting for the next release?

Hoping we may find a solution quickly! Thank you very much for your help,

SJ.

[sjahan]

Here are some updates on the problem.

We're getting closer and closer: altough using that kind of characters is quite weird, this goes well while the node name is handled by the Modeshape code.

The issue happens in the Hibernate code. I've never used directly Hibernate so i can't tell why this isn't working. After some searches on the web, i found out that i could probably solve this by overriding the MySQL5InnoDBDialect, which i did:

import org.hibernate.dialect.MySQL5InnoDBDialect;

public class MySQL5InnoDBUTF8Dialect extends MySQL5InnoDBDialect {

    public String getTableTypeString() {

        return " ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci";

    }

}

The trouble is that it still doesn't work and we're starting to have no clue at all

Hoping someone has or will encounter the same problem and can help us....

Thank you by advance,

SJ.

[sjahan]

Nevermind about the encoding trouble, the checkin is definitely ok! I found out that the connection string modified to support UTF-8 wasn't the proper one. Dumb issue Sorry for bothering, i'll finally be able to test this morning the versioning!

Have a good day,

SJ.

[sjahan]

Hi again!

We didn't completely finish yet the versioning module!

We got though a lot of issues, we rethink from scratch a special versioning area, etc. Now everything works: i version what i want, in the way i want, and i can browse the frozen nodes (which was my first issue at the beginning ).

The last problem we're encoutering is with restore(). That worked back in Modeshape 1.2, but since i upgraded to 2.5, our restore code doesn't work anymore.

Our former code was: node.restore(version, true);

Like this was deprecated, i changed it to:

VersionManager vm = session.getWorkspace().getVersionManager();

            vm.restore(version, true);

Same result: neither effects nor exceptions.

My version is a Version object (from JCR), casted to Version from the Node /jcr:system/jcr:versionStorage/bb/bf/7a/7d/f673-43ef-96c5-f85df8e5e529/2011-07-20T150710.156+0200

Is this the proper object to pass in parameter?

Has someone an idea about what's happening or should i go for a debug session?

The version Node is written by Modeshape and i don't write it manually, so i don't understand why restore doesn't work...

Hoping someone got some clues about it,

Thank you by advance for your help,

SJ.

[rhauch]

VersionManager vm = session.getWorkspace().getVersionManager();

            vm.restore(version, true);

Same result: neither effects nor exceptions.

My version is a Version object (from JCR), casted to Version from the Node /jcr:system/jcr:versionStorage/bb/bf/7a/7d/f673-43ef-96c5-f85df8e5e529/2011-07-20T150710.156+0200

Is this the proper object to pass in parameter?

Has someone an idea about what's happening or should i go for a debug session?

I'm not sure how you're finding that Node you're casting to Version, but you should be able to get the version history for the node and find the Version you want to restore. (Version nodes are also returned by the 'checkin(...)' method, but I suspect you won't have the right Version when you want to restore.)

For example:

VersionHistory vh = vm.getVersionHistory("path/to/node");

Version version = vh.getVersion(versionName);

Instead of getting the version by name, you can also get the version using "vh.getVersionByLabel" if you have a label on the version, or you can iterate through the versions in the history to find the right one. Whichever method works the best.

You can then pass this Version object into the 'vm.restore(Version,boolean)' method.

Now, ModeShape has a number of unit tests that verify the restore functionality, and we also pass the TCK tests for restore. So we know it's working at least in some cases. If it's not working in your case, please debug the method and see what is going wrong during the restore.

Best regards!

[sjahan]

Hi Randall,

I solved this problem which was finally quite stupid... Now the restore function is efficient, but not as much as expected. I'd like to check with you that is the expected behavior, if so, i'll implement what i'm expecting on my side.

Here is the last problem: after a restore, i have strange things happening on mixins. Actually, when i check in a node, everything is correctly stored into the JCR's versionStorage area, including the child nodes and their mixin (here, only referenceable).

But when i restore a node, everything goes fine excepts that i loose the mixin on the child node. No more referenceable on the nodes i'm working on, so no more UUID, which is quite annoying for us

Is it specific to my case, or is it the way it works/is supposed to work?

That's looking strange. If this is normal, i guess i could code a loop to browse the child and put back a mixin but before getting heavier on this part, i wish to check with you if this is normal or not.

Thank you very much by advance,

SJ.

-- UPDATE --

Finally, i just can't add a loop to set the mixin, after the restore: i must obviously check out before adding the mixins, then check in after, which will waste my version hystory

Are we supposed to manually edit the version history? How could i deal with that problem?

After some debug, i found out that in the JcrVersionManager, line 1095, the variable called shouldRestoreMixinsAndUuid isn't set to true and that leads to not restore the mixin i want. This is because of the fact that the children of the frozen node haven't the primaryType equals to jcr:frozenNode.

But that's the Modeshape check-in method which stores the frozen node's children with the original primaryType and not with jcr:frozenNode so i'm entirely depending on Modeshape code on that matter i suppose.

Is it a bug or where have we gone wrong on that matter?

Thank you for your support.

[rhauch]

But when i restore a node, everything goes fine excepts that i loose the mixin on the child node. No more referenceable on the nodes i'm working on, so no more UUID, which is quite annoying for us

Is it specific to my case, or is it the way it works/is supposed to work?

No, it is not supposed to work that way. ModeShape should be restoring the mixins as you expect. IOW, it should just work.

After some debug, i found out that in the JcrVersionManager, line 1095, the variable called shouldRestoreMixinsAndUuid isn't set to true and that leads to not restore the mixin i want. This is because of the fact that the children of the frozen node haven't the primaryType equals to jcr:frozenNode.

But that's the Modeshape check-in method which stores the frozen node's children with the original primaryType and not with jcr:frozenNode so i'm entirely depending on Modeshape code on that matter i suppose.

Is it a bug or where have we gone wrong on that matter?

It's definitely a bug. Can you please report it as a bug in our JIRA? Please reference this discussion thread. Also, since you're in the debugger, can you describe the path through JcrVersionManager so we can more quickly figure out why that 'shouldRestoreMixinsAndUuids' is not being set to 'true'?

We hope to release 2.6.0.Beta2 early next week, so if you can log it soon we can hopefully get a fix in for this.

[sjahan]

Logged in MODE-1228

Hoping you'll find how to resolve this for your next release!

Have a good day,

SJ.

[rhauch]

Thanks for logging that! I hope to get that fixed this week.

Can you clarify some things? The node being restored has mixins, correct? Does it have any children, and if so do they have mixins, and what is the OPV value of the node types for these child nodes? Could you describe what the versionable node structure looks like? I'm primarily interested in the primary type, mixin types, the OPV values of each of the node types, and which node in this restored structure does not have the mixins.

[sjahan]

The structure of the nodes is the following:

One node N, mix:versionable.

Under N, one child, let's call it C. C's OPV is COPY. mix:referenceable.

Primary types are extensions of nt:unstructured to drive the OPV. Every node is COPY for now. The oea:copyUnstructured that you could find previously in this topic.

When i checkin, i get under my version a frozen node of N, the primary type is frozen in jcr:frozenPrimaryType, and then it becomes jcr:frozenNode.

Under the frozen node of N, i get a proper copy of C.

When i restore N, the original N is properly restored (mixin included).

C is also properly restored, except there is no mixin anymore, and so i miss jcr:uuid and jcr:mixin = mix:referenceable.