RE: [CDBI] Dealing with non-required primary keys

>=20

>=20
> > > 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."
>=20

By "this way" I mean this:

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

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

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

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