Imo the 'Natural Key' logic pretty close to a @Index(unique=true). But with a very special logical meaning.
JPA doesn't know a logical key yet, but it might be nice to think about such a fundamental thing.
LieGrue,
strub
----- Original Message -----
> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Cc: Steve Ebersole <steve.ebersole_at_redhat.com>
> Sent: Tuesday, May 22, 2012 11:23 PM
> Subject: [jpa-spec users] [jsr338-experts] Re: Re: Fwd: Re: Re: JPA schema generation
>
>
>
> On 5/22/2012 2:16 PM, Steve Ebersole wrote:
>> Did I miss JPA adding @NaturalId ?
>>
>
> No, JPA doesn't have a @NaturalId annotation.
>
>>
>> On Tue 22 May 2012 01:07:11 PM CDT, Linda DeMichiel wrote:
>>> My reply on the thread....
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [jpa-spec users] [jsr338-experts] Re: JPA schema
> generation
>>> Date: Mon, 21 May 2012 13:01:43 -0700
>>> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
>>> Organization: Oracle Corporation
>>> To: struberg_at_yahoo.de
>>>
>>> Hi Mark,
>>>
>>> On 5/21/2012 12:18 PM, struberg_at_yahoo.de wrote:
>>>> Hi lords and ladies!
>>>>
>>>> I originally replied to this thread on 9th already, but it seems it
>>>> didn't get through. Trying again via the webmail.
>>>
>>> Thanks for your perseverence -- this is helpful.
>>>
>>> Your email went only to me though. Are you a member of the jpa-spec
>>> project? If you are, you should be able to post to the
>>> users_at_jpa-spec.java.net
>>> email list.
>>>
>>>> ---------------
>>>>
>>>> I basically share the same sentiment regarding automated schema
>>>> creation.
>>>>
>>>>
>>>> Maybe I'm understanding your approach the wrong way, so I
> better sync
>>>> up:
>>>>
>>>> * You like to have the EE container create the schema at deploy
> time or
>>>> runtime if you add a new tenant?
>>>> * For production as well? Or only for tests?
>>>>
>>>
>>> It depends on the app. Please see below.
>>>
>>>> I hope I got this wrong, because I've never seen a big project
> where
>>>> you do _not_ need one of the following
>>>> * additional tables for non-jpa use (e.g. accessed via nativeQuery
> or
>>>> even JDBC)
>>>> * additional indices for performance tuning
>>>> * sometimes even non-portable indices (Oracle Text Search)
>>>> * doing manual statistic runs or enabling automatically scheduled
>>>> statistic runs
>>>> * setting up tons of other stuff: triggers, stored procedures, db
>>>> replication to other nodes, etc
>>>
>>> I'm not going to disagree with you on any of the above
>>>
>>>> * where do you get the required db privileges from?
>>>>
>>>
>>> There are 2 distinct cases here in my view:
>>>
>>> (1) the application (aka JPA provider) "owns" the database --
> this
>>> corresponds to the separate-database provisioning case, where the
> tenant
>>> is allocated a database rather than just a schema in a database. In
>>> this case,
>>> the platform provider hands the JPA provider a datasource that has
>>> been properly
>>> configured for the provider to create schemas and tables in the
> database.
>>>
>>> (2) the application (JPA provider) owns only a schema in the database,
>>> and receives a datasource that restricts access to that schema. In this
>>> case, the provider will be restricted to creating tables within that
>>> schema.
>>>
>>>>
>>>> In the projects *I* know, you most times cannot even use the
>>>> auto-generated stuff for your testing db. This feature is imo
> really
>>>> only good for small samples which use in-memory derby or hsqldb. Of
>>>> course, the generated schema is the base (and really good), but
> most
>>>> times you need many manual steps in addition.
>>>>
>>>
>>> Agree
>>>
>>>> So, did I get the intention wrong?
>>>>
>>>
>>> I think so. At least we seem to be in agreement AFAICT.
>>>
>>> In more complex scenarios and for production apps, I'm expecting
> schema
>>> generation to be a multi-phase process. Perhaps there in an initial
>>> schema generated by the JPA provider (and output as DDL) which is then
>>> tuned by a database expert (eg DBA) to the needs of the application.
>>> That resulting schema might then be submitted as DDL packaged with the
>>> application. Assuming the target database type is known (which I am
>>> assuming
>>> it is in such cases), that DDL might be used to produce
> database-specific
>>> artifacts such as you suggest above.
>>>
>>>>
>>>> Regarding the Indexes. I'd rather have a typesafe @Index
> nnotation
>>>> which allows for own typesafe index groups.
>>>> Just a very first idea:
>>>>
>>>> public @interface Index {
>>>> int value() default Integer.MAX_VALUE; // for ordering the index if
>>>> no group annotation is used
>>>> boolean unique() default false;
>>>> // add asc, desc etc and other stuff as you like
>>>> }
>>>>
>>>
>>> Not sure I'm following. I was proposing that if the index included
>>> multiple
>>> columns that the @Indexes annotation would need to be applied to the
>>> class.
>>>
>>>>
>>>> @Entity
>>>> public class MyUser {
>>>>
>>>> // @Index meta-information to show that this is an index group
>>>> private @Index(unique=true)@interface LoginId {
>>>> int value() default Integer.MAX_VALUE; // mandatory for @Index
>>>> groups: for ordering inside the grp
>>>> }
>>>> private @Index_at_interface CarLookup {
>>>> // if no int value() is specified in an index, the order is
>>>> undefined
>>>> }
>>>>
>>>> @LoginId(1);
>>>> private String tenant;
>>>>
>>>> @LoginId(2);
>>>> private String userLogin;
>>>>
>>>> @CarLookup
>>>> private String carVendor;
>>>>
>>>> @CarLookup
>>>> private String carType;
>>>> }
>>>>
>>>>
>>>> The
>>>> @Index an groups should also be respected when sorting the query
>>>> criterias. For older DBs you still sometimes need unnecessary
>>>> nativeQueries just to get the order right to match the data (first
>>>> query
>>>> criteria should let you get rid of most data). Not sure if this is
>>>> still true nowadays with the latest DBs but I think even Oracle10
> had
>>>> problems with queries which didnt fit the order of the index.
>>>>
>>>
>>> Please explain further. A good query optimizer should consider the
>>> indexes.
>>> (But that doesn't *guarantee* that the result would be in that
> order)
>>>
>>>>
>>>> Maybe
>>>> for logicalKeys we could do something similar to EmbeddedId for
>>>> @NaturalId. Automatically generating a unique index for those
> fields
>>>> and
>>>> making them usable in em.find(MyEntity, mylogicalKey) ...
>>>>
>>>
>>> Beyond a certain point I start worrying about too many indexes being
>>> added - and that being counterproductive.
>>>
>>>> More about it in JPA_SPEC-22
>>>>
>>>>
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>>
>>>>
>>>> PS:
>>>> hello everybody and thanks for the hard work on JPA! I'm some
> random
>>>> old jerk who started writing DB frameworks some decades ago on the
>>>> mainframe (in C on OS/360), and use/write db stuff in Java since
> late
>>>> 90s or so.
>>>
>>> OS/360? Wow.
>>>
>>>> PPS: plz excuse me if I miss something obvious...
>>>
>>> I don't think you have. Thanks again for taking the trouble to
> write
>>> this up.
>>>
>>> -Linda
>>>
>>>
>