Hi Rainer,
I do not know any of serious applications which are deployed into production without staging. So at the end every application is at least 3 times tested until it moves to production...
I would never allow an ORM tool to change my schema in directly production. DDL-generation is a very useful feature for development / testing. Right now it has to be configured in proprietary way.
I like Emanuel's idea of ddl generation.
Because openJPA, Hibernate, EclipseLink, JPOX and probably others already come with create, drop, drop-and-create DDL functionality. Why not standardize this property?
Just because it could cause trouble in production? (as actually everything else :-))
thanks!,
adam
On 01.07.2011, at 17:37, Rainer Kwesi Schweigkoffer wrote:
> 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.
>
>
Independent Consultant, Speaker, Java Champion
Weblog: blog.adam-bien.com
press: press.adam-bien.com
eMail: abien_at_adam-bien.com
twitter: twitter.com/AdamBien
Mobile: 0049(0)170 280 3144
Author of:
"Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"