Dealing with object versions 2

[DPisarev]

Hi, all,

Investigating the feasibility of the J2EE platform for my needs, I have come upon this theoretical question. Suppose I write and deploy my J2EE application but then there arises the need for me to change the attributes of some object in it.

For example, suppose my app has a certain "ContactPerson" object but a few months after deploying the application and creating hundreds of ContactPerson instances in the database I realize I need to associate a new attribute with each one of them -- like their Internet telephony ID.

In the most basic of terms, then, what is the J2EE capability/procedure for inserting a new field into an already existing application object definition without losing any data associated with its instances but rather supplementing those instances with the new attribute? So, in my example, I wouldn't want lose any existing data stored in my ContactPerson object instances but would want to seamlessly migrate that data to the new, expanded definition of ContactPerson. Any suggestions on how this is done in J2EE?

Thanks in advance,
D. P.

 

[sedj]

J2EE is a term covering many, many technologies/APIs. What specifc one are you referring to ? In what respect are you creating this "ContactPerson" object, and more importantly how/what API are you using it in ?

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[chiph]

Generally, everything must be in sync when you add new columns (or more importantly, change or delete columns) to your data.

So, it's something that you'll have to manage through your configuration management process -- using your souce code control system, merge utility, automated build, etc.

Ideally, you'd update your data dictionary and pass it around to the development team, saying "We're adding this new value to the ContactPerson entity -- make your code handle it properly". You'll need to create a branch in the source code system for them to do their work in (you want the old branch to continue to exist separatly so that bugs that get reported can be fixed).

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[DPisarev]

Thanks for your replies, guys. Let me provide the clarifications you're asking for.

What J2EE technology/API do I intend to use? I was thinking about EJBs. I know that to the programmer EJBs look more or less like normal Java objects but store their fields in the rows of a back-end database. And so I wondered -- what if you need to, say, add a new column to that database after the application has gone live and data has been entered into it: naturally, re-coding the EJB's is easy enough: you just declare an additional field inside your ContactPerson.java file. But, when compiled, will objects of this new class definition still be able to access all that DB data your previous-version EJB instances had access to?

Perhaps it will help if I cast it in different words still. Suppose my EJB app has entered the production mode and our organization has created hundreds of ContactPerson instances in it. Now, we don't want to lose or ever re-enter any of that information; we just want to add to it. So I expand the definition of the class ContactPerson to include my new field (e.g. "String InetTelephonyID;"). Then I recompile ContactPerson.java and place its new binary in my app server's classes directory. My question is, will instances of this essentially re-defined ContactPerson class still have access to all that data to which the old compilation did, or must I re-enter all previously-stored ContactPerson data into the application?

Hope it's clearer this time.

 

[chiph]

Uhh, all those instances are hopefully storing their state in a database. The database would (typically) be where'd you start your change process by adding those columns to the tables used.

Changing your schema will require you to change your objects, and you'd manage that thru the process I described earlier.

I would suggest you pick up a copy of:
Software Configuration Management Patterns: Effective Teamwork, Practical Integration
ISBN: 0201741172

It describes the software configuration management process, and gives good examples of how to apply it.

Chip H.

____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Diancecht]

I think that mostly relies on the design of the application. It's difficult to believe that any platform or system has an easy way to change design on a production environment.

Those changes, at least in my opinion, use to be a complicated issue that involves coordination from a few of departments ang angry customers.

So I don't think you can state if J2EE is suitable or not for it, as it depends on a lot of external factors, EJBS, WAS, DBs, etc.

Cheers,

Dian

 

[DPisarev]

Chip, Dian, thanks for your input. But I still wonder what is the typical way to migrate data between different versions of an EJB application in the real world? I don't suppose re-entering all the data is a favorite with people? Or maybe it is but they just have a very nifty way of automating it?

Dmitri.

 

[chiph]

You usually have to write a migration utility. It would open the old database and the new database (which might be the same DB), and perform the operations needed to convert it to the new schema, which may include DDL statements to add tables, columns, drop & re-add indexes, etc. as well as copying the data over.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[DPisarev]

Thanks for the reply, Chip; it is getting interesting!

Yet modifying DB tables directly sounds to me like getting slightly too deep "under the hood": it's easy to introduce a change into your tables that the app will fail to recognize properly afterwards...

I wonder if it would instead be a good idea to, say, have the app go into a special mode where it would grab all the old entity objects and write them out to disk (as persisted .class files). I'd then run a utility on those saved objects that will turn them into newer-version entity beans. After that these new objects would be read back in by the app and stored in its back end. Does this sound feasible and reasonable at all, in your view?...

One problem area I can see with this approach myself is having the objects inter-referenced. I can't see how I'd maintain their links to each other during the disk dump.

Thanks,
Dmitri.

 

[sedj]

As far as I understand this, your question is this :

"With EJB, if you have a bean mapped to a table, and then add another field to the bean, then will this invalidate the table, or will adding another column have no effect on the previous data" ?

Is this what you are asking ? Now I don't know the answer to this, but it would be easy to find out - just try it !
I would imagine that the answer is that it is possible to add another field to a table & bean without losing data. To not have this capability would be completely insane - as is the idea of dumping the entire database to a bunch of serialized classes. We hold tables that have over half a billion records - that would be years to dump into a bunch of serialized classes - not to mention the terrabytes of disk space.

My advice would be to give it a whirl !

BTW, on another topic, I would seriously advise against using EJB altogether, but thats another story

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[DPisarev]

Sedj,

You understood me perfectly. I just wanted to see if messing with J2EE was worth it at all before taking the plunge. But now that I'm leaning toward using it anyhow, I guess your suggestion to just give it a try makes the best sense.

If anyone wants to share more thoughts on the topic, though, that would be most welcome.

Dmitri.

 

[chiph]

I wonder if it would instead be a good idea to, say, have the app go into a special mode where it would grab all the old entity objects and write them out to disk (as persisted .class files).

I still get the impression that you're confusing the data, as represented in memory, with the data, as represented in the database. One of them must be considered authoritative -- ie. the true source of the data -- It's almost always the database. If that's so, then any migration effort must begin there.

If you want to write your entity bean to recognize the old schema as well as the new schema -- I'm not sure how to do that, maybe Sedj has an idea. But I would say that you should follow his suggestion & create a small test app to test that situation.

I would think that having the beans know about the old format will work, up to a point. If the DB schema changes are too severe, this may not work for you. Again, the answer would be to write a test app to see how far you can go before you break stuff.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[sedj]

Chip, EJB is all about mapping a representation of one (or more) tables in one Java object (bean). The idea is that when you update the bean, the db is physically updated also. The db is always the authoritive data source in EJB. The real question is whether an EJB can understand a change in the table it maps to. It may be tricky if you start linking EJBs/tables via primary keys actually from the EJB side, but if you write your EJB & db design carefully, these obstacles should be not too bad.

If your schema will change a lot (especially with primary & foreign keys) I would try to keep your beans to a simplistic one-bean-one-table mapping, and stay away from fancy key bindings and EJB-QL.

Personally however, I still think there are too many db-esque operations in EJB to be efficient, but thats another argument.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[DPisarev]

Chip,

Well, I was under the impression that my EJB's would be mapped to database rows *transparently*. That is to say, as the coder I would only manipulate Java objects (EJB's) and would not see how they are stored in the database. So, if I could access all of my data through the EJBs, I thought that I would be able to make a backup of all of that data by just dumping these entity EJB's to disk in serialized form...

Of course, any subsequent changes to the EJB's fields must eventually be reflected in some database modifications -- I just supposed it would be better to leave the job of recreating/modifying the DB to the EJB's themselves -- so that they would register those DB changes in the way they are most comfortable with.

Otherwise, what's the guarantee that after I manually change the DB and recompile the EJB's with new fields added in, as you suggest, -- what is the guarantee that the new EJB definitions will recognize the new DB structure?

In any case, I just know that there must be a tried and proven way of doing all this! Someone surely must have needed to tweak their EJB definitions after their application had gone live and critical information had been stored in it!

D.P.