views:

55

answers:

1

As described here, I want to update the user's database by means of catching the exception that occurs when the entity classes don't match. I understand that I could add a catch statement to every db-interface method, but that's error-prone*. Other 'polling methods' are also possible, but they are not interrupt-driven as I want through catching exceptions.

I think what I'm looking for is to catch the exception before it's delivered to the user (possibly to crash the application). I would put there my catch block. I'd have put it in the main() in a non NB app.

  • My understanding is that the exception is thrown on an entity basis (i.e. a method that involves only one entity, which has not changed, will not throw any exceptions, although other entities have changed).
A: 

Since my post doesn't seem to have appeared on the netbeans-dev list, I post it here as well:

This is an interesting question. I have a similar problem, but I guess mine is a bit harder to solve. I use JPA at server side, and the server is actually a webservice provider. The persistence is managed by the container, and according to my app settings, it uses a "Create" strategy. Of course, every time I change my entities and redeploy the application it throws a lot of exceptions . What I finally decided to do is to create/migrate the existing database in a separate process. This is, reading the metadata associated to the entities and comparing it with the current database. Afterwards, it creates a migration script in case the db schema is diferent to fit it into the new one without losing any information (the migration script generation complexity depends on how do you plan to handle cases like data type changes or attribute removal). The last step is redeploying the app (in your case start it).

I'd suggest a proactive approach, where you don't wait for the exception to be thrown, but trying to guess the changes before to run the application.

Charles Bedon
that's the difference btw polling and interrupt-driven. I feel the latter is much more efficient and 'natural'.
simpatico