[CDBI] Dealing with non-required primary keys
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
> > > the typename; the RDBMS will take care of that. What is important
> > > 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
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
> > > accomplished in Class::DBI? I should mention that "don't use
> > > keys" isn't really an option. I need to use primary keys because
> > > using quite a few "has_a" relationships in other modules that use
> > > 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
> 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');
Is there another way you're using foreign keys in has_a() relationships?
> ClassDBI mailing list
> ClassDBI at lists.digitalcraftsmen.net
More information about the ClassDBI