I would try to use MDA techniques to generate the data move logic. I would not generate ordinary SQL but Hibernate-QL or EJB-QL, depending on the component models of the old and new version of the system.Maybe the tool itself should use hibernate, to insulate itself from the work that has already been handled by it with dialects.
After thinking this over a bit more, I think plain SQL will do it. AFAIK, it should be possible to write the data migration in SQL92. Are there much implementation variations on the basic CREATE, ALTER, DROP INSERT and DELETE commands for Oracle, PostgreSQL, DB2 and SQLserver?
Best wishes for 2004, Pieter.
Pieter Van Gorp wrote:
Thanks a lot Brian,
I would try to use MDA techniques to generate the data move logic. I would not generate ordinary SQL but Hibernate-QL or EJB-QL, depending on the component models of the old and new version of the system.Maybe the tool itself should use hibernate, to insulate itself from the work that has already been handled by it with dialects.
Of course, there may be several iterations of the model between what isWell, if I would really deploy application server components to achieve DBMS portability, it would get tricky if there are a lot of structural changes between two production releases... my first guess would be that each "move attribute" refactoring would require a deployment for both the old and new component version and execute the moves between them. After the move, the old deployment can be removed, the next version is deployed, the data is moved according to the refactoring between the last two versions etc. I must admit this sounds a bit crazy but AFAIK it is the only way to automatically port your data in a DBMS "independent" way...
running in production and what is about to be deployed. The key value in
this tool is that it could collect all those changes automatically.
I'm already playing with the idea for some months and it could become my low-profile hobby project. The more people that are interested, the more motivation for me to get started on it. Brian, you're right about the need for a DBA review of the data move statements. Anybody else with tips on industrial relevance / applicability?
Best regards, Pieter.
Brian Topping wrote:
A few thoughts on this:
Neat idea, but how can you make it so that it doesn't rely on any given database or OR mapping? Maybe the tool itself should use hibernate, to insulate itself from the work that has already been handled by it with dialects.
So I guess what you are talking about is something that generates a file full
of SQL for when the app is being deployed to production? It should be
something that a DBA can review and apply manually, after the code has been
tested and we are about to deploy the new version of the app. Of course, there may be several iterations of the model between what is
running in production and what is about to be deployed. The key value in
this tool is that it could collect all those changes automatically.
As for doing this during iterative development, I'm not sure that this is so
important. Developers have learned to move fast with iteratively updating
tables -- the hard thing is remembering all the changes that went into the
tables over the course of days!
Especially in a team environment where these many small changes are
multiplied by many developers, a tool that can generate an overall DB table
upgrade script (one that reflects the upgrades that were generated by all the
developers and could be scrutinized by the DBA before deployment) could be
interesting to me.
$0.02
-b
-----Original Message----- From: Pieter Van Gorp [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 5:18 AM To: [EMAIL PROTECTED] Subject: Re: [Andromda-devel] SQL Cartdrige
Hi,
I have been thinking about something else: generating and executing SQL to move data from old to new tables when doing a move field refactoring on an entity.
Somebody interested in such a feature? I could make some of my time available...
Best regards, Pieter.
On maandag, dec 22, 2003, at 23:18 Europe/Brussels, Matthias Bohlen wrote:
Hi all,
is a SQL cartridge really necessary? EJB creates its tables
on the fly,
Hibernate auto-generates a DDL script for that. It seems as if we already have what we need.
My 2 cents... Matthias
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wouter Zoons Sent: Monday, December 22, 2003 10:34 PM To: Miguel Griffa Cc: [EMAIL PROTECTED] Subject: [normal] Re: [Andromda-devel] SQL Cartdrige
I have been thinking about this too, generating an initial-load for the DB depending on the tables
I think it is a good idea to use the Entity stereotype (be careful 'Entity' will soon become 'entity', lowercased, as per UML convention) since typically this is associated to a table in the implementation
avoid introducing stereotypes where possible
my 2 cents
Miguel Griffa wrote:
I'm working on a cartdrige to generate SQL scripts for db
creation. Do
you think it's usefull this? I have some working code I could submit...
On the other hand, I have used as stereotype <<table>> Do you think I should use Entity?
Thank you all
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an
expert in LINUX or just sharpen your skills. Sign up for
IBM's Free
Linux Tutorials. Learn everything from the bash shell to
sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=> 3371&op=click
_______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
