[CDBI] Dealing with non-required primary keys

John Drago john.drago at data393.com
Sun Sep 4 04:35:41 BST 2005


> 
> > > It's not really important to add a constraint to Class::DBI to
handle
> > > the typename; the RDBMS will take care of that.  What is important
is
> > > how to deal with the typeid.
> >
> > What do you mean - "how to deal with the typeid"?
> How to tell Class::DBI that the typeid is a generated by the database
upon
> insertion.

It sounds like you're running into problems with auto-increment fields.
I've used Class:DBI on MySQL and Postgres without any problems.  What
database are you having issues with?

> >
> > > So what would you recommend?  Is this a technical feat that can't
be
> > > accomplished in Class::DBI?  I should mention that "don't use
primary
> > > keys" isn't really an option.  I need to use primary keys because
I'm
> > > using quite a few "has_a" relationships in other modules that use
the
> > > primary keys I'm using.
> >
> > Is there something preventing you from doing it this way?
> >
> "has_a" relationships are used in linking foreign keys to primary
keys.
> If you don't correctly specify the primary keys, then they don't work.
> If this explanation isn't sufficient, you're going to have to expound
> upon what you mean by "this way," as I'm taking it to mean "not using
> primary keys."
> 

By "this way" I mean this:

  Music::CD->has_a(artist => 'Music::Artist');
  print $cd->artist->name;

Is there another way you're using foreign keys in has_a() relationships?

> 
> _______________________________________________
> ClassDBI mailing list
> ClassDBI at lists.digitalcraftsmen.net
> http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi





More information about the ClassDBI mailing list