[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dali-dev] Re: schema for JPA connections
|
I was thinking of Oracle, DB2, Sybase (dbo is alias), Derby, and MS SQL
2000. But, at least in some cases, these are defaults that can be
changed, so it is true that having a universal default doesn't always
work. As I mentioned in the bug, we really need to query the DB to
determine what the default schema is for a particular login. If this is
not possible, then we have to allow the user to set a default schema for
their login.
We will target a solution for 1.0.2 that either allows us to obtain the
default setting from the DB, or we implement all of the major defaults
based on DB.
Defaults can currently be found in
org.eclipse.jpt.db.internal.DTPConnectionProfileWrapper.getDefaultSchema().
Neil
Max Rydahl Andersen wrote:
Hi Neil,
Also, schemaName = userName is not an absolute, but is rather a
default that matches runtime behavior (on most DB's - when using
PostgreSQL, the default schema is actually "public", and Dali
reflects this).
Where are these defaults setup ?
Afaik Oracle is the *only* db that has username=schema.
PostgreSQL - PUBLIC
Mysql - dependent on jdbc url connection string
Db2 - (not sure since I don't have it installed to verify)
HSQLDB/H2 - PUBLIC (use extensively during dev thus important)
MSSQL - dbo
My suggestion is two fold:
1) Implement the default behaviors for all major db's (see above,
needs verification of course ;)
2) That we get a persistence provider hook that allow us to read the
vendor-specific setting in persistence.xml for default schema.
IMO #1 should go into WTP 2.x since it shouldn't break any API.
#2 I guess have to wait.
/max
> This is
the way things are going to work at runtime when setting your JDBC
userName in the provider properties. This default is properly
overridden in the orm.xml persistence-unit-defaults, or as specified
by annotation, or as specified in the orm.xml for a given element.
There are a LOT of places to set the schema, depending on the
granularity that you need. This JPA meta data is the where schema
information is stored.
Our validation has to take into account all of these possible schema
settings to determine whether a database object can be resolved for a
given Entity/Mapping. There is no master, all overriding, tool-only
schema setting. We have too many schema settings to keep track of as
it stands. ;) There is a possible argument for having this, but with
so many existing schema settings and defaults, I worry that by
removing confusion on the tooling side with a simple setting, you
might complicate issues when you try to run your application and
don't get the results that you expect.
As for Entity Generation, this does create a bit of an issue when
generating from the non-default schema. I'll carry that conversation
forward in the bug, but it probably needs some discussion to
determine the best course of action.
Neil
Tom Mutdosch wrote:
Thanks Adrian,
That does seem to be a pretty big limitation. In looking at that
bug, it mentioned that the proper way to specify the default schema
was to set it in the orm.xml. I have actually tried that approach
many times without success (using both Toplink on Glassfish as well
as open-jpa). That is, I set up the orm.xml properly, but the
schema was ignored. I got the impression that the Java-annotated
entities actually took precedence over any value specified in the
orm.xml I actually asked on both of those mailing lists and the
answer that I got seemed to be that the best way to set the schema
was through the provider-specific properties. Can anyone confirm
this? Or has anyone had success specifying a schema via the orm.xml?
Thanks
Tom
Message: 2
Date: Thu, 11 Oct 2007 17:39:12 +0200
From: "Goerler, Adrian" <adrian.goerler@xxxxxxx>
Subject: AW: [dali-dev] schema for JPA connections
To: "General Dali EJB ORM developer discussion."
<dali-dev@xxxxxxxxxxx>
Message-ID:
<8DD10CADA07AFC4DB4F550CE8D63619F046F1329@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Hi Tom,
I think this is the same issue as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195095
My understanding of the situation is that schemaName=userName is
hardwired, currently.
Adrian
-----Ursprüngliche Nachricht-----
Von: dali-dev-bounces@xxxxxxxxxxx
[mailto:dali-dev-bounces@xxxxxxxxxxx] Im Auftrag von Tom Mutdosch
Gesendet: Donnerstag, 11. Oktober 2007 17:24
An: dali-dev@xxxxxxxxxxx
Betreff: [dali-dev] schema for JPA connections
Hi all,
Is the schema stored somewhere for the current Dali connection? I
generated entitees from a non-default schema (ADMINISTRATOR) and I
am seeing validation errors like:
"Schema "db2admin" cannot be resolved for table "Department"
'db2admin' is the user name/default schema, not the schema that I
used to generate entities. I thought I used to be able to set the
schema on the JPA Property page, but I may have imagined that. Is
there somewhere where this is stored? Note that I'm using the Dali
1.0 maintenance stream.
Aside from validation, I'm interested in this because I'm trying to
write some tooling to update the persistence.xml with the schema
that the user generated entities from, such as:
<properties>
<property name="openjpa.jdbc.Schema"
value="ADMINISTRATOR"/>
</properties>
I need some way to figure out which schema was used when generating
entities. I figured this must be stored somewhere in order to do
validation. Is there a way that I could get that information somehow?
Thanks
Tom
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
------------------------------
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
End of dali-dev Digest, Vol 25, Issue 1
***************************************
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev