Hi Adam, all,
Adam Bien, am 30 Jun 2011 hast Du um 11:50 zum Thema "[jsr338-experts] Standardization of additional pe" geschrieben :
> Hi all,
>
> proposal for standardization of table generation strategy:
>
> <property name="javax.persistence.table-generation-strategy" value="CREATE | DROP-AND-CREATE | MIGRATION | NONE /> Default should be NONE.
>
> I would like to propose MIGRATION as an optional parameter. In this case the JPA provider is expected to alter the tables, instead of drop and recreate them,
>
> any thoughts?
this sounds like a feature that might be very helpful to application
developers, but also pretty complex to implement and not so easy to
standardise, imho.
It depends, of course, on what scenarios you are having in mind to be
supported.
There could be developers gradually developing and deploying an
application, who would like to see their test data to be kept over
their deployments.
One could imagine an application vendor delivering an application and
later updates of this application to their customers, who want the
customer data to survive the updates. Table changes during development
of those updates could alreay have accumulated to something quite
intricate.
However, a specific customer could have modified their installation of
the application, and the update of the application could run into
conflicts with the customer's modification.
Even if you intend to support simple changes only, there might be,
depending on the underlying database platform, alterations of a table
that may be performed as catalog operations or in place by the database
rather quickly, others that trigger an implicit table data conversion
on the database server, which, based on the amount of data, might not
return before hours or even days, and finally those that cannot be done
by the dbms and that would force the jpa provider to either give up or
implement some kind of table data conversion on their side.
Probably, rather than having the jpa provider figure out how to alter
the database objects, you would end up with some way allowing the
application developer to specify what modifications should be applied
to the tables and other structures on the database, like it is
apparently the case with the Active Record feature you have been
pointing us to.
So far my Euro 0.02.
Best regards
Rainer
---
Rainer Schweigkoffer SAP AG Walldorf
Business Solution & Technology TD Core JS&I
Technology Development Dietmar-Hopp-Allee 16
Java Server Core D-69190 Walldorf
JEE Implementation Group phone: +49 6227 7 45305
Building 3, I.3.14 fax: +49 6227 7 821177
rainer.schweigkoffer_at_sap.com
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.