Well, what I was envisioning would be safe in a multi-process environment. It would not be selecting the max id of the table, but rather selecting the id of the row that was inserted by using as conditions the values of the fields of the object that was just saved
Even that is not safe, since you are relying on the fact that all your data (aside from the primary key) will be unique. This is okay if you have other uniquness constraints on the table, but otherwise you will eventually run into a problem with this. Most systems of this nature rely on the primary key as the natural unique identifier, I would really suggest you stick with that, and subclass for different DBDs.
| [reply] |
On a related thread, I'm wondering what is the most elegant way to organize the classes with which I am doing subclassing with respect to locating the code and namespacing. Under whatever namespace I eventually use, I have an Object class (we'll call it Whatever::Object) that lives in an Object.pm file. I also have classes Whatever::Object::Query and Whatever::Object::ResultSet, which live respectively in the files Query.pm and ResultSet.pm in a sub-directory called Object. So, the directory structure is something like...
lib/
Whatever/
Object.pm
Object/
Query.pm
ResultSet.pm
Now, relevant to our original thread, the Object class has a save method that either inserts the object into the database, or updates an existing record. The method, in a very non-DBD-agnostic way, currently grabs the mysql_insertid from the statement handle. What I want to do is change my Object constructor to bless the thingy into a subclass, e.g. Whatever::Object::MySQL, and that class will provide a save method that will deal with the assignment of surrogate primary key values in a DBD-specific fashion.
From the perspective of a class relationship hierarchy, it's clear in my mind. What is not clear to me, however, is where the subclass really ought to live. I suppose it could just live in the Object directory, e.g. in a file called MySQL.pm, along with Query and ResultSet, but that feels weird to me... It feels odd because in the case of Query and ResultSet you have the .pm files living somewhere simply because of namespacing, whereas in the case of the Object subclass for MySQL, it's living there because Object is its base class. Is it right for me to feel that this would be weird, or is this the standard way to it? The only alternative that I can fathom would be to put the MySQL class definition inside the Object.pm file. Would that be better or worse, and is there any other alternative?
| [reply] |
It feels odd because in the case of Query and ResultSet you have the .pm files living somewhere simply because of namespacing,
Maybe that is not the best place to put Query and ResultSet then? If I were to guess, I would have thought they were more kind of like "inner-classes", meaning classes that Object used internally, OR that they were subclasses of Object. However, if they are actually on the same "level" as Object, I would recommend mimicing that in your directory/namspace structure. Keep in mind that you are adding a top level namespace Whatever::, which maybe can hold Object, Query and ResultSet for you?
Is it right for me to feel that this would be weird, or is this the standard way to it?
Trust your feelings young skyknight. Maybe you should try lowering the blast sheild. A true Perl Jedi does not need his eyes :P
Oh yeah, and no, there is no standard way of doing it, at least that anyone has told me :)
The only alternative that I can fathom would be to put the MySQL class definition inside the Object.pm file.
Yuk. Besides this will only temporarily solve your problem since someday you (or someone else) will need to write a PostgreSQL/Oracle/MSSQLServer/etc subclass for this and you will have to deal with it then.
Now, based on my still limited knowledge of your code, I would suggest moving Query and ResultSet up to the root namespace (since as you say they are only in Object for the namespace). This will allow you to easily place all subclasses in subdirectories. And while right now all you can see a need for subclassing is Object, you never know if at some point you may need to subclass Query or ResultSet as well. Doing it this way leaves that door open just in case.
lib/
Whatever/
Object.pm
Object/
MySQL.pm
PostgreSQL.pm
Oracle.pm
Query.pm
Query/
MySQL.pm
Oracle.pm
ResultSet.pm
ResultSet/
Interbase.pm
| [reply]
[d/l] |
Most systems of this nature rely on the primary key as the natural unique identifier, I would really suggest you stick with that, and subclass for different DBDs.
I'm not sure that I entirely agree with that. It's legitimate to have another unique identifier. You just don't want to be using it as a foreign key in another table. The argument for having surrogate primary keys is that they are meaningless as anything except a row identifier, having no semantic meaning as far as your data is concerned, and thus are non-volatile and consequently safe to use for linking objects/rows together.
I agree with your assertion that subclassing is the right thing to do. I just don't think that the primary key has to be the only unique identifier. For example, think of a user table... The user id is going to be unique. It would be a bad idea to use it as a foreign key in link tables, but it would be unique all the same.
Anyway, I'm not sure what I'm arguing anymore... I didn't get enough sleep last night and am not entirely coherent. :-)
| [reply] |
For example, think of a user table... The user id is going to be unique. It would be a bad idea to use it as a foreign key in link tables, but it would be unique all the same
Quite true, but that is what I mean about "another uniqueness constraint". Personally, I usually call this "user_name" and have "user_id" be a auto increment primary key :).
The only reason I keep pushing this idea is that I have been bitten by it in the past. And in a OO-relational mapping class as well (although it was a custom class, and not a full system like yours). In the end I wrote a DBI wrapper which handled the differences between MySQL's 'last_insert_id' and PostgreSQL's 'pg_oid_status' which gave me a basic level of DBD agnosticism (well at least the DBD's I cared about that is).
Anyway, I'm not sure what I'm arguing anymore... I didn't get enough sleep last night and am not entirely coherent. :-)
Two words: Mountain Dew :)
| [reply] |