Re: [CDBI] Class::DBI classes with a default primary key

[prev] [thread] [next] [Date index for 2005/08/25]

On Tue, Aug 23, 2005 at 01:51:01PM -0400, marcus baker wrote:
> i've inherited a table from someone else (that i'd rather not alter),
> setup somewhat like this:
> 
> CREATE TABLE mytable (
>     userid  INTEGER NOT NULL,
>     building VARCHAR2 (100),
>     room VARCHAR2 (100),
>     browser VARCHAR2 (500),
>     cdate TIMESTAMP(6) DEFAULT current_timestamp NOT NULL
> )
> 
> note that nothing is auto incremented, and that no actual primary keys
> have been set.
> 
> i'd like to integrate the table into Class::DBI, defining the two
> columns of 'userid' and 'cdate' as primary keys.  create() fails under
> that setup, as Class::DBI wants both primary keys defined in the
> hashref passed in.  is there a way to let Class::DBI proceed creating
> without having specified the cdate column, since it's generated by the
> system?
> 
> i understand that i could programmatically set the cdate column in the
> hashref passed to the create() method, just alter the table to have
> 'real' primary keys, or just set any other column as a primary key and
> run the search() method instead of retrieve() when it's needd, but i
> would like to know this kind of information for future reference.

Surely userid is unique? In which case you'd be better off seting only userid
as a primary key? I *think* that then when you call create CDBI will note
that it hasn't INSERTed that value and mark it do be fetched from the db
when it's required in the usual lazy-loading-by-column-groups fashion.

If it doesn't, you should be able to kill that attribute in an after_create
trigger, I would've thought. Those more familiar with this sort of use case
than I may have better ideas, though.

        -- 
             Matt S Trout        Specialists in OSS web application development and
  Technical Director    UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi