Schema Evolution Question

The documentation indicates that " In client-server mode the ObjectDB server must be restarted after a schema change. "  It is unclear whether the client application with the upgraded schema must connect to ObjectDB before the restart or whether ObjectDB can be restarted while the client is down and then have the client with the upgraded schema connect.

That is to say, is it valid to perform the following steps:

1. Stop old client application.
2. Stop ObjectDB.
3. Start ObjectDB.
4. Start NEW client application.

Or, is it necessary to do the following:

1. Stop old client application.
2. Start NEW client application (errors will occur due to "Field xxxx not found in type yyyy")
3. Stop ObjectDB
4. Start ObjectDB

Thank you!

The correct steps are:

1. Stop old client application with the old schema.
2. Stop ObjectDB server.
3. Start ObjectDB server.
4. Start new client application with the new schema.

I followed these steps in the prescribed order.

1. Stop old client application with the old schema.
2. Stop ObjectDB server.
3. Start ObjectDB server.
4. Start new client application with the new schema.

The application immediately threw errors when trying to read the new schema (before any new records had been written):

NoSuchFieldException: consultationProcessed
com.objectdb.o._PersistenceException:45
com.objectdb.o.JPE:145
com.objectdb.o.ERR:56
com.objectdb.o.OST:599
com.objectdb.jpa.EMF:177
com.adheris.cap.capfoundation.objectdb.AbstractObjectDatabase:87
com.adheris.cap.summaryframework.database.SummaryStagingDatabase:75

It may be worth noting that the table that was being read by the client application was EMPTY.

SUBSEQUENT restart of ObjectDB and client after attempting to access with new schema caused the error to go away.  So, in testing experience, the following sequence of steps appear to be required (although I don't understand why):

1. Stop client application (old schema)
2. Start client application (new schema).  Errors will occur. 
3. Stop client application.
4. Restart ObjectDB.
5. Start client application.  Errors are gone.

Do you have any thoughts on why the simpler "stop old schema client/restart ObjectDB/start new schema client" approach didn't work?  Again, notable - the table (with the old schema) being read by the client using the new schema was empty.

Thank you for this report.

An improved management of schema changes in client-server mode is definitely a top priority for future ObjectDB versions, and the final goal is to support schema changes with no need to restart at all.

In order to investigate this issue further could you please provide full stack traces of the exceptions. You may be able to find the full stack traces (including exception causes) in the log files.

When the server starts it generates synthetic classes based on the schema of the database. It seems that an attempt to change this schema later (when an update is sent by the client) fails.

A possible workaround is to run the server with a classpath that includes the new class files, although your workaround is also fine. The error messages can be ignored as they are gone after another restart and cannot damage the databases.