Thanks Chuck. I guess I'll put the table names for abstract entities
back in, especially if it is a problem with FrontBase (but not
OpenBase). Just another one of those examples where trying to be
clean comes back to bite you ;-)
Ian
On 14/12/2005, at 12:04 PM, Chuck Hill wrote:
Hi Ian,
Abstract or not, it is always a good thing to give each entity a
table name and to generate the SQL for the table. This is to
handle various DB specific oddities. The one below is a good
example. For another, FrontBase associates the primary key
generator with a table. So, even though the table for the abstract
super class will never have any rows in it, it needs to be created.
I don't think this is a bug, just an artifact of varying
implementations of a database. Kind of makes you long for a
standard, doesn't it?
Chuck
On Dec 13, 2005, at 4:59 PM, Ian Joyner wrote:
I have a slight problem that when I SQL generate particular tables
in EOModeler, with 'Create Tables' and 'Primary Key Constraints'
set, I get a null index created, which SQL complains:
Error from JDBC adaptor: EvaluateExpression failed: <OpenBasePlugIn
$OpenBaseExpression: "create index null PRIMARY_KEY">:
Next exception:SQL State:42000 -- error code: 0 -- msg: SQL
ERROR - [position 12, near '
' in 'eate index null PRIMARY_K'] Index Table Error: table name
expected but not found.
SQL: [EMAIL PROTECTED]
The generated SQL is:
CREATE TABLE IMAGES (OWNER_KEY longlong NOT NULL, PRIMARY_KEY
longlong NOT NULL, TYPE char(1) , URL char(128) );
ALTER TABLE IMAGES ADD PRIMARY KEY (PRIMARY_KEY);
create unique index IMAGES PRIMARY_KEY;
create index null PRIMARY_KEY;
delete from _SYS_RELATIONSHIP where relationshipName = 'owner' and
source_table = 'IMAGES' ;
insert into _SYS_RELATIONSHIP (relationshipName, source_table,
source_column, dest_table, dest_column, operator, one_to_many)
values ('owner','IMAGES','OWNER_KEY','null','PRIMARY_KEY','=',0);
The cause of this problem is that the table IMAGES has a
relationship to anything you can have images of, all of which
inherit from an abstract, tableless entity name 'Artiffact'.
Hence, relationship 'owner' is defined as:
owner: owner_key -> Artifact.primary_key
but since Artifact's table name in the inspector is null, I get
the null in 'create index null PRIMARY_KEY;'. All subclasses of
Artifact of course have unique primary keys wrt Artifact. This
does not seem to have any adverse impact on the operation of the
DB. Should I be worried, or define the model in a better way?
Should this be reported as a bug to Apple?
Thanks
Ian Joyner
Sportstec
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/
practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
