Forward compatibility

Question

I have one concern with using JDO broadly that has to do with forwards
compatibility. I'm hoping someone with more knowledge of JDO can address
this for me. I know that not all the classes I ship today will be the same
next year. When I change them, say adding or removing a field, and upgrade a
production system, I will need to retain all the data stored by JDO in the
database and move to the new class format.
How does JDO handle this? If JDO does not handle this, how do I work around
this (severe) limitation?
Thanks,
Brian.

Answer 1

Brian,
If you add persistent fields to your class, then the schema must
necessarily change. If you add fields that are not persistent or
simply change methods in an existing PC class, then the schema does
not change. If you refactor your classes, so that now the
persistent fields are in different classes, then you will have to
map the new object model onto the preexisting data model, which
might be difficult or impossible depending on the degree of change,
and the flexibility of the mapping tools supplied by Kodo or
whatever implementation that you use. It's not been my experience
that it is easy even with JDBC to make radical changes to the schema
or to the model of persistent objects. Adding a persistent field or
a new persistent class are the lightweight types of changes that
Kodo and most implementations will accommodate.
If the changes to your classes require changes to your schema
then you have the same deployment issues with JDO that you would
have with JDBC. Whatever approach that you currently use to roll
these changes out should work with JDO.
The degree of backward compatibility that new versions of your
application must provide for existing data is dependent on the
requirements. So far as I can see, JDO doesn't make it harder to do
and doesn't make it easier either.
Whatever datastore you use maintains persistent state in some
schema or format. When you make changes to your persistent classes,
it is your choice whether those changes will affect the datastore
format. If they don't, then you're not adding, moving, or deleting
persistent fields. If they do, then your datastore will dictate
somewhat what types of changes are easy and what are hard. The
mapping tools may allow you to mask somewhat the effects you are
having on the persistent format, but that road doesn't go far.
It's an interesting question. Are you suggesting that there is
value in tools that would allow the mapping to continue to mask the
changes, even if that masking would (as would be likely) decrease
the efficiency of data access?
David Ezzio
Brian Cort wrote:
>
thanks for the prompt reply. About this schema tool and the upgrade process,
this doesn't seem like it would work in the general case of shipping an
upgrade off to a customer. They won't have the schema tool and they
certainly won't know anything about the design of the software. They'll just
get the updated .class/.jar files to install and will expect everything to
work.
The only case I can think of where this tool would be useful would be for
internal use at a company that both develops and uses their own software. Am
I wrong?
--Brian.
"Eric Lindauer" <[email protected]> wrote in message
news:[email protected]...
Hi Brian,
JDO as a specification does not address this issue, as far as I know.
Handling changes between versions will be a differentiator between JDO
implementations. Kodo already handles this issue to some degree, though
admittedly not perfectly. When you add a field to an existing class, the
schematool that comes with Kodo is able to recognize the change and add
columns to the database, maintaining the old tables. When you delete a
field, the tool removes the needed columns. You do not have to regenerate
tables whenever you make a change to your object.
The more complicated the change you make, the more you may need to write
your own conversion classes. Generally speaking though, if you keep track
of what you have changed and how the new object maps to the old object,you
should be able to do the conversion.
Hope this helps.
-Eric
"Brian Cort" <[email protected]> wrote in message
news:[email protected]...
I have one concern with using JDO broadly that has to do with forwards
compatibility. I'm hoping someone with more knowledge of JDO can address
this for me. I know that not all the classes I ship today will be the
same
next year. When I change them, say adding or removing a field, andupgrade
a
production system, I will need to retain all the data stored by JDO in
the
database and move to the new class format.
How does JDO handle this? If JDO does not handle this, how do I workaround
this (severe) limitation?
Thanks,
Brian.