I have been seeing this problem recently working with EO's stored
in MySQL as well. If I create an object and save it out to the
database (and in my case, we allow EOF to generate the primary key
as it sees fit) and then manipulate it and re-save it immediately,
I get an error similar to that described below - evidently because
of some type mismatch. If I refetch the object later, I can edit
and resave without issue, as the key types are consistent.
These entities had their PK fields stored as INTEGERs in the db,
and in EOF had a datatype of 'Long - Long l' - which is how
EntityModeler reverse-engineered them. Looks like the EOs were
getting created with an 'Integer' primary key field initially, as
setting the Datatype to 'i' seemed to fix the problem.
So could this same problem that Mike fixed with the FB plugin also
be affecting the MySQL interface as well?
That sure sounds like the same problem. I had thought that the
problem that Mike fixed was one that was unique to that plugin.
Perhaps the problem is in EOF. It certainly seems reasonable to
expect the plugin to generate keys of the correct type as defined in
the model.
IIRC that bug was a result of some code that depended on
describeResults() to determine the data types of the generated pks.
However, describeResults seems to consistently screw me -- there's not
always reliable info in that metadata to get the attribute values
right. I believe I switched the FB version over to manually construct
the fake attributes on the fly for the PK generation ... I think EOF
is already doing this for the MySQLPlugIn (or rather does it in the
JDBCPlugIn), though.
ms
_______________________________________________
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]
