Re: compound primary key ("failed to provide new primary keys")
Re: compound primary key ("failed to provide new primary keys")
- Subject: Re: compound primary key ("failed to provide new primary keys")
- From: Johann Werner <email@hidden>
- Date: Sat, 14 Jun 2008 20:55:49 +0200
Hi Gavin,
did you check "Propagates Primary Key" on the Author and Advert entity?
jw
Am 14.06.2008 um 18:31 schrieb Gavin Eadie:
I've twisted myself into a knot and would appreciate a little
untangling help.
EOF makes so much easy that I get lulled into the idea that I know
what I'm doing ...
WebObject 5.4.2, recent Wonder, Mac OS 10.5.3, MySQL 5.1.23 db
Three tables: Author, Advert, Select ... legacies that I don't have
control over (and the real tables contain more unrelated
information). The original tables are in Oracle and I used Entity
Modeler to derive a model, changed it to use ERPrototypes so I could
make types canonical, and used that to generate a MySQL database for
testing the logic of a re-write (incorporating Wonder) of the
business logic around this structure.
Author +----+
| ID | PKey
+----+
| .. |
+----+
| .. |
+----+
| |
Advert +----+
| ID | PKey
+----+
| .. |
+----+
| .. |
+----+
| |
Select +----------+
| authorID |
+----------+
| advertID |
+----------+
A Select connects one Author to one Advert; Author can have many
Selects, as can Adverts -- simple stuff.
The Select table has no primary keys (in Oracle both attributes were
"indexes" but not primary keys, but this doesn't translate, as far
as I can tell, to MySQL -- ans if it did, not to Entity Modeler).
The result is that Entity Modeler complains -- and EOGeneration
dons't run. So I made both attributes primary keys (they both need
to be, because neither would be unique in its own right), and
generated my EOGenericRecord classes, etc.
In my code I call:
Select.createSelect(_ec, author, advert);
and I get:
Adaptor com.webobjects.jdbcadaptor.JDBCAdaptor@1701fd failed to
provide new primary keys for entity 'Select'
at
com
.webobjects
.eoaccess
.EODatabaseContext
.prepareForSaveWithCoordinator(EODatabaseContext.java:5713)
at
com
.webobjects
.eocontrol
.EOObjectStoreCoordinator
.saveChangesInEditingContext(EOObjectStoreCoordinator.java:370)
at
com
.webobjects
.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192)
at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:968)
I could allow setters on authorID and advertID, but that doesn't
seem right. It would force the exposure of the IDs on Author and
Advert and I generally try to treat primary keys as database
artifacts and keep them out of my code.
I'm not a WO novice, but I do keep feeling like one as I explore its
depths. I'm a single developer without the benefit of nearby
buddies with whom I can talk this kind of thing through with (and my
wife loses interest pretty quickly!); this list IS my buddies so be
gentle if I seem to be an idiot!!
Ultimately, my question is, "What is the right way to do this?" ..
where "right" includes correctness AND goodness! Thank you .. Gav
<Picture 1.png>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden