List:General Discussion« Previous MessageNext Message »
From:Jim O'Quinn Date:October 8 1999 8:49pm
Subject:Re: finding AUTO_INCREMENT type from client side
View as plain text  
> > T_SOME_TABLE.ID               - auto_increment
> > T_SOME_TALBE.SOME_CHAR                - char
> >
> > my $obj       = new T_SOME_TABLE();
> > $obj->setSomeChar(12);
> > $obj->store;  # does update/insert
> >
> >Then I can do:
> >
> > print $obj->getSomeChar;      # a '12' shows up
> > print $obj->getId;            # here is where I need to get
> >                                # the value that was auto_incremented
> 
> Jim, don't you need to know before you do the update/insert, whether
> it's auto_increment or not?  Otherwise you don't know if you need to
> supply a value (which value, by the way?) or NULL (auto_increment).
> You're already assuming something about the ID column, it seems to me
> (although, obviously, I've only got a scrap of an idea about what you
> are doing).

Yup, you are on top of it.  The above was just
one example of why I need to automatically
figure out wether it is AUTO_INC or not.  My 
'old-school' way of incrementing needs to be 
compaitable with the new AUTO_INC way and I 
can make adjustments in my base class with out 
effecting all the apps that currently use the 
obj-rel interface.  I need to willy-nilly
change the ID field (I already make an assumption
that if the the 1st field is called ID it is
an automatically incremented field) from  a plain 
ole INT or to INT AUTO_INCREMENT with out having 
to recode any programs.  All newer databases
will be created with AUTO_INC, but I've got
a bunch of leagcy junk that I don't want to
mess with.

In the example above, the store() method
would look at the ID field and figure out
if it needs to 'lock, select, increment,
update, unlock' or just insert a NULL
(plus store() knows if you need to do an insert
or an update). Post-insert, it needs to stuff
the newly incrementd value in a hash so I can 
get to it later--here again I need to know 
if it is AUTO_INC or not.

In any case, all this junk runs under Apache
mod_perl and I'm thinking about caching all
the database meta-data in the web server on
web server startup where I can pull it from 
a variable and not have  to run an extra SQL 
statement and parse the results to determine 
if I've got a AUTO_INC or not, plus pulling 
it from a variable is faster than makeing 
db calls to get the  meta-data.  All of this 
came about b/c of performance tweaking anyway.


Whew!  Thanks for you help!

Jim



> I'm not trying to avoid the real question.  I should, because I don't
> know how to get this out of Mysql.pm (short of hacking Mysql.pm, which
> is a dead duck anyway, so I don't know how useful that would be).  But
> I am trying to figure out if there isn't a better way to organize your
> program, so that you don't need to find out if the id is auto_increment
> or not.  Perhaps you could structure it so that every table that is used
> in this way MUST have an auto_increment id.  Then you know the answer
> even before you start.  Or perhaps you could store a logical (to your
> class, that is) table definition when you create the tables, which lets
> you know all sorts of good stuff about the tables in question, including
> whether or not they have auto_increment IDs.
> 
> Sorry for the rambling prose - I'm rather scattered at the moment.
> 
> Tim
Thread
finding AUTO_INCREMENT type from client sideJim O'Quinn7 Oct
  • Re: finding AUTO_INCREMENT type from client sideThimble Smith7 Oct
  • Re: finding AUTO_INCREMENT type from client sideJim O'Quinn7 Oct
    • Re: finding AUTO_INCREMENT type from client sideMichael Widenius8 Oct
  • Re: finding AUTO_INCREMENT type from client sideJim O'Quinn8 Oct
    • Re: finding AUTO_INCREMENT type from client sideThimble Smith8 Oct
  • Re: finding AUTO_INCREMENT type from client sideJim O'Quinn8 Oct
    • Re: finding AUTO_INCREMENT type from client sideThimble Smith8 Oct
    • Re: finding AUTO_INCREMENT type from client sideMichael Widenius10 Oct