Eclipse Community Forums: EMF » [CDO] RootResourceID is null error

Home » Modeling » EMF » [CDO] RootResourceID is null error - Workaround

[CDO] RootResourceID is null error - Workaround [message #1838709]

Wed, 03 March 2021 20:16

Eclipse User

I was getting the "RootResourceID is null error" with CDO 4.12 - which some have also had in the distant past. I'm upgrading from 4.1 but it seems others were seeing it earlier than this? I was able to perform a workaround. Here's the background. In AbstractCDOView this method is called when opening a transaction from the client and if the root resource id is not set then it fails the call.

public void setSession(InternalCDOSession session)
{
rootResourceID = session.getRepositoryInfo().getRootResourceID();
if (rootResourceID == null || rootResourceID.isNull())
{
throw new IllegalStateException("RootResourceID is null; is the repository not yet initialized?");
}
}

I hadn't needed to set this before in the 4.1 client so I tried to track down where the root resource id can be set but none of the places were obvious in the client and the null value was coming from the server repo info returned to the client. I was also unable to determine where to set that value in the server. It may be related to workspaces or importing server configuration - its unclear.

So to work around the issue I added this code before the call to open the transaction. I saw in one case in the code that the a resource was being compared to the path "/" in order to determine if it was root. So I went with that. e.g.

RepositoryInfo repoinfo = ((RepositoryInfo)session.getRepositoryInfo());
repoinfo.setRootResourceID(CDOIDUtil.createString("/"));

transaction = session.openTransaction();

And that's working. I should mention though that I haven't created a resource at the path "/" in my db, just passed a CDOID object initialized with that value. I'm fine with the workaround but if anyone can explain the requirement for this check on the root resource - or what has changed between 4.1 to 4.12 to require it then I'd be interested to know. Especially if this work around comes back to haunt me somehow.

Re: [CDO] RootResourceID is null error - Workaround [message #1838729 is a reply to message #1838709]

Thu, 04 March 2021 03:31

Eclipse User

I don't think your workaround is sensible because You should first find out why the rootResourceID is null:

1) On the server it's computed at startup time by Repository.readRootResource(). In the DBStore that reads the CDORESOURCE table row with FOLDER==null and NAME==null and should most commonly return the CDOID 1.

2) When the client connects to the repository it reads the rootResourceID from the server in OpenSessionRequest.confirming().

3) You've already found the place where the rootResourceID is used when openeing a CDOView.

Can you spot the earliest place where the rootResourceID is null?

Re: [CDO] RootResourceID is null error - Workaround [message #1838764 is a reply to message #1838729]

Thu, 04 March 2021 12:41

Eclipse User

Yes I agree, it was only a workaround until there was an explanation for what the root resource is and why its checked for. Thanks for point 1), I was trying to figure out where it was loaded but couldn't find it.

After debugging the CDO server I've found that the root resource is not being read during server startup. The AbstractHorizontalClassMapping.initTable() method is trying to load resource tables named "eresource_CDOResourceFolder", "eresource_CDOResource", "eresource_CDOTextResource" and "eresource_CDOBinaryResource" which aren't defined in my schema. Instead I have tables called ERES_CDORESFOLDER, ERES_CDORES, ERES_CDOTEXTRES and ERES_CDOBINARYRES. It looks like the ERES_CDORES table contains the root resource that we're looking for.

The question then is why are the table names different? The DB migration was completed successfully and it ran the two SchemaMigrators in DBStore that weren't null objects. The ones executed changed the name of the LOB size field in the LOB table and the other cleaned up objects in the CDO_OBJECTS table that had a cdo_version less than the branch's first version. So no migration step to rename tables. Is this issue part of a greater migration tool that I haven't run? Can I reconfigure CDO to use my tables using the mapping strategy or, the oracle db store or something?

Re: [CDO] RootResourceID is null error - Workaround [message #1838793 is a reply to message #1838764]

Fri, 05 March 2021 02:11

Eclipse User

So the root cause of the "missing" root resource is the difference between old and new table names. The new and longer names look correct/expected to me.

The question remains, what in your old installation caused these weird shorter names to be created/used?
Perhaps you have a chance to debug your old server installation. A breakpoint in AbstractMappingStrategy.getTableName() will be helpful...

And no, there's no "greater migration tool" other than your eyes and hands :P

Re: [CDO] RootResourceID is null error - Workaround [message #1838820 is a reply to message #1838793]

Fri, 05 March 2021 12:21

Eclipse User

I still have the snapshot of the CDO 4.1 source base that I deployed from so yes I'll check that to see how the shorter names came about. My vague recollection is that the table names were too long for oracle and I remember that when I was first deploying CDO on oracle that there was a particular person who had developed the oracle plugin for CDO which at the time wasn't supported. Maybe they had devised the way to automatically shorten the table names for oracle? Do you remember who that might have been? Maybe with oracle 19 there isn't an issue with table names this long now so that's another avenue I can check.

Also I only mentioned a "greater" migration tool because when I first posted about upgrading from 4.1 to 4.12 you actually noted that this would be a good test of the migration. It sounded like a tool, but I see now that its the two SchemaMigrator class implementations.

Re: [CDO] RootResourceID is null error - Workaround [message #1838835 is a reply to message #1838820]

Fri, 05 March 2021 18:25

Eclipse User

Update on this: I'm not sure why the resource tables were named differently in 4.1 but I was able to rename the tables to the new naming convention and start the server and make some basic queries. And of course I could remove the workaround that I mentioned above as it wouldn't have worked anyway since any queries to the new tables after that point would have failed anyway.

Re: [CDO] RootResourceID is null error - Workaround [message #1838852 is a reply to message #1838835]

Sat, 06 March 2021 12:52

Eclipse User

Perfect!

I don't remember the history of the OracleAdapter, but it's all in Git. Today there's this:

public int getMaxTableNameLength()
{
return 30;
}

But that still doesn't explain why the package prefix is shortened before the complete table name is concatenated. I'm sure that nothing in CDO does that today....

Re: [CDO] RootResourceID is null error - Workaround [message #1838853 is a reply to message #1838852]

Sat, 06 March 2021 12:56

Eclipse User

If I look at your old table names:

ERES_CDORESFOLDER
ERES_CDORES
ERES_CDOTEXTRES
ERES_CDOBINARYRES

I can't fight the feeling that they're all hand-made. Are you sure that the mapping strategy of your repo isn't customized?

Re: [CDO] RootResourceID is null error - Workaround [message #1838863 is a reply to message #1838853]

Sat, 06 March 2021 22:47

Eclipse User

I've searched the CDO 4.1 snapshot source tree that I have and the deployed directory as I thought it may have been in the cdo-server.xml or somewhere but no, I can't find how those names were manually configured. Strangely, any code that accesses those tables would also need to use those table names for this to have worked so it would have to be a low level change. Of course I still have to get the debugger working with the CDO 4.1 source tree and then debug the method that you mentioned to see where the table name comes from, but my work priority is getting the latest server working with my client so its on the back burner for now.

Previous Topic:	Ecore - inherited derived attributes
Next Topic:	Use .jar as Xtext resource

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 12 18:54:52 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter