Forwarding to the group as Mark's request.....
-------- Original Message --------
Subject: Re: [jpa-spec users] [jsr338-experts] Re: JPA schema generation
Date: Mon, 21 May 2012 19:18:26 +0000 (GMT)
From: <struberg_at_yahoo.de>
To: linda.demichiel_at_oracle.com
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.
---------------
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?
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
* where do you get the required db privileges from?
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.
So, did I get the intention wrong?
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
}
@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.
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) ...
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.
PPS: plz excuse me if I miss something obvious...