On 05/08/2005, at 6:06 PM, Anjo Krank wrote:
Am 05.08.2005 um 09:53 schrieb LD:
I've using 4 simple models. I can see the benefits even with my simple list of entities. The annoying thing, however, is with EOModeler. i.e., if I define some prototypes with properties for value type, value class, allowsNull etc but _without_ a column name - then when I assign that prototype to an attribute that already has a column name the silly thing will remove the column name after you close the model.
Which is part of what I meant. There are a lot of other quirks, too, most of which I forgot as we now have our own prototypes handling (one that actually works:)
In the mean time (before I can incorporate PW) the test will be whether or not changing the prototype will muck things up again - meaning you need to go through "all" of your entities to fix the problems it causes. That kind of undermines the usefulness of prototypes to a point.
Hence the use of the PostgresqlPlugIn.framework. Works well (with my slight alteration to the plugin).
What "alterations"?
The alteration was to the HexDreams 1.2 version (see below [1]). Now, you're going to tell me that Project Wonder already has a better postgresql plugin. It's okay - you can say it ;-)
[snip code]
Well... I don't know what the rationale is behind that fragment, but in the worst case, you get three additional DB roundtrips *per insert*.
The rationale was simple: get it working ;-)
I'm not sure why the assumption in the framework was made about sequence names (unless older versions of PostgreSQL used different sequence names by default) but I could have changed it to utilise the single scheme that I use (i.e., the postgres default scheme) but I thought while I was at it, I'd cover a couple of other bases.
I'd rather make it so the serial's name is in the entities or PKs userInfo and it will choose that instead of trying the names nilly-willy...
It's the sequence name you need in the userInfo. The serial's name is simply the name of the pk's column name...
==
8.1.4. Serial Types
The data types serial and bigserial are not true types, but merely a notational convenience for setting up unique identifier columns (similar to the AUTO_INCREMENT property supported by some other databases). In the current implementation, specifying
CREATE TABLE tablename (
colname SERIAL
);
is equivalent to specifying:
CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
colname integer DEFAULT nextval('tablename_colname_seq') NOT NULL
);
Thus, we have created an integer column and arranged for its default values to be assigned from a sequence generator. A NOT NULL constraint is applied to ensure that a null value cannot be explicitly inserted, either. In most cases you would also want to attach a UNIQUE or PRIMARY KEY constraint to prevent duplicate values from being inserted by accident, but this is not automatic.
Note: Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer automatic. If you wish a serial column to be in a unique constraint or a primary key, it must now be specified, same as with any other data type.
To insert the next value of the sequence into the serial column, specify that the serial column should be assigned its default value. This can be done either by excluding the column from the list of columns in the INSERT statement, or through the use of the DEFAULT key word.
==
or you do it your way and set the value in the userInfo after the first discovery.
That would be good to do if the sequence name is not found in the userInfo. How would you set this in the userInfo from EOModeler?
If you make a patch to the Wonder plugin (which is of course much better, shiny and brighter:), I'll see that I can integrate it.
I've just looked at the source for the Wonder plugin and it makes the same (non-postgres-standard) assumption about the sequence name. So, I'll have a look at implementing both your suggestions...