cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias SCHOESSLER <Tobias.Schoess...@unvienna.org>
Subject Re: best practice for handling database schema changes
Date Mon, 04 Dec 2006 09:44:50 GMT

<br><font size=2 face="sans-serif">I see this discussion very interesting,
but my initial question was less how to manage the schema changes of the
database, than how to manage the cayenne mapping changes. I wonder what
are the difficulties in implementing a merge of changes found in the db
schema into an existing mapping when performing the 'reverse engineer from
database function' in the modeller . </font>
<br><font size=2 face="sans-serif">Merging db schema changes into the mapping
information seems to be a common operation and I wonder why it hasn't been
implemented in cayenne just yet. &nbsp;Especially as cayenne seems to have
a strong emphasis on the usability of the mapping process with its integrated
modeller. Something I recall other ORM tools don't have at all (e.g. hibernate).
</font>
<br>
<br><font size=2 face="sans-serif">(I would never ask this on a commercial
help forum, nor expect a true answer ; ) &nbsp;), but what about the competitors
? Is this 'merge schema changes into existing mapping' feature so exotic
that it is not adhoc supported in other ORM tools? <br>
</font>
<br><font size=2 face="sans-serif">regards</font>
<br>
<br><font size=2 face="sans-serif">Tobias<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Malcolm Edgar&quot;
&lt;malcolm.edgar@gmail.com&gt;</b> </font>
<p><font size=1 face="sans-serif">Sunday, 3 December 2006 23:49</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
cayenne-user@incubator.apache.org</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">cayenne-user@incubator.apache.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: best practice for handling
database schema changes</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>I have also used a very similar approach on another
project. &nbsp;We used<br>
Java commands to perform each version update, the advantage of this<br>
over straight SQL files is that you can migrated data using Java logic<br>
into the new schema.<br>
<br>
regards Malcolm<br>
<br>
On 12/4/06, Aristedes Maniatis &lt;ari@ish.com.au&gt; wrote:<br>
&gt; Interesting article. We implemented something similar, but without<br>
&gt; hard coding the SQL to update the schema into Java. Instead we have
a<br>
&gt; folder full of files named 1.sql, 2.sql, etc. Each one contains the<br>
&gt; SQL required to update the database schema. Every time the server<br>
&gt; application runs it reads a special table in the database with one<br>
&gt; column and one record. That value is the 'schema version' from the<br>
&gt; last launch of the application. If this number is lower that the<br>
&gt; largest xx.sql file in the folder, then that sql file is executed
and<br>
&gt; the version updated.<br>
&gt;<br>
&gt; We do all this before Cayenne is intialised in any way in our<br>
&gt; application.<br>
&gt;<br>
&gt; The only thing we haven't yet done is to write a junit test that<br>
&gt; validates the sum total of all our incremental updates is the same
as<br>
&gt; a single SQL export from the current Cayenne model.<br>
&gt;<br>
&gt; Ari Maniatis<br>
&gt;<br>
&gt;<br>
&gt; On 02/12/2006, at 12:56 AM, Michael Gentry wrote:<br>
&gt;<br>
&gt; &gt; I found this yesterday (although I haven't read it all yet):<br>
&gt; &gt;<br>
&gt; &gt; http://www.stepwise.com/Articles/2005/DBChanges/index.html<br>
&gt; &gt;<br>
&gt; &gt; Not sure if it'll be helpful, but it looks similar to some ideas
I had<br>
&gt; &gt; been pondering in the past.<br>
&gt; &gt;<br>
&gt; &gt; /dev/mrg<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On 11/30/06, Michael Gentry &lt;blacknext@gmail.com&gt; wrote:<br>
&gt; &gt;&gt; Currently you have to manually merge the changes just as
you states.<br>
&gt; &gt;&gt; I should probably make an FAQ for this ...<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Thanks,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; /dev/mrg<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On 11/30/06, Tobias SCHOESSLER &lt;Tobias.Schoessler@unvienna.org&gt;<br>
&gt; &gt;&gt; wrote:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; hi,<br>
&gt; &gt;&gt; &gt; What is the best practice for handling changes to the
database<br>
&gt; &gt;&gt; schema once a<br>
&gt; &gt;&gt; &gt; cayenne mapping was created?<br>
&gt; &gt;&gt; &gt; We use the 'reverse engineer from database' feature
to create an<br>
&gt; &gt;&gt; initial<br>
&gt; &gt;&gt; &gt; mapping. But then we usually have to do manual changes
like map<br>
&gt; &gt;&gt; some pks,<br>
&gt; &gt;&gt; &gt; add flattened relationships, etc.<br>
&gt; &gt;&gt; &gt; If then the database schema needs to be changed we usually
have<br>
&gt; &gt;&gt; a problem as<br>
&gt; &gt;&gt; &gt; 'reverse engineer from database' overwrites everything.
There<br>
&gt; &gt;&gt; seems to be<br>
&gt; &gt;&gt; &gt; the possibility to replace only selected tables but
if you do<br>
&gt; &gt;&gt; this the<br>
&gt; &gt;&gt; &gt; relationships are messed up. Is there a way to &nbsp;merge
the<br>
&gt; &gt;&gt; changes with the<br>
&gt; &gt;&gt; &gt; current model/mapping?<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; thanks<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Tobias<br>
&gt; &gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --------------------------&gt;<br>
&gt; ish<br>
&gt; http://www.ish.com.au<br>
&gt; Level 1, 30 Wilson Street Newtown 2042 Australia<br>
&gt; phone +61 2 9550 5001 &nbsp; fax +61 2 9550 4001<br>
&gt; GPG fingerprint CBFB 84B4 738D 4E87 5E5C &nbsp;5EFA EF6A 7D2E 3E49
102A<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</font></tt>
<br>

Mime
View raw message