Re: Need help with finding solution to CDBI bug

[prev] [thread] [next] [Date index for 2004/06/21]

On Mon, Jun 21, 2004 at 09:04:58PM +0300, Yuval Kogman wrote:
> > I meant map in the sense of using a map function like the one that
> > Charles B. suggested which converts object references into literal
> > values.
> 
> My reply to him explains how this breaks - stringification does not
> always use the id, and furthermore, has_a relationships in the fields
> returned by id are stringified into it. See below.

But is the stringification bug the same as the map function that I'm
talking about? It seems that the id function is where you see the
problem. Granted I suppose it could be argued that id() should return
literal values instead of references to objects.


> > No, I mean multiple primary keys which could hold a foreign key as in a
> > many-to-many relationship. Is this considered multiple foreign keys? If
> > so, the docs for doing Many-to-many relationships seem to me to suggest
> > using multiple foreign keys via the following table definition:
> > 
> >     Role->table('role');
> >     Role->columns(Primary => qw/film actor/);
> 
> That's one primary key... You can't be assured by the database that only
> one row will have film so and so. You need both the field and the actor
> to retreive the rrole.

So you're saying it's a single primary key composed of two fields?


> >     Role->has_a(film => 'Film');
> >     Role->has_a(actor => 'Actor');
> 
> And these are foreign keys. In this case the fields for the primary key
> are also foreign keys themselves - each one contains the value of a
> primary key in another table. I think (i hate this jargon, it's not 100%
> logical).

No kidding!


> > > See the failing test case I mailed Tony - it retreives an object whose
> > > primary key has_a. I can give the numerical IDs of the key fields, or I
> > > can give the objects that were inflated. I'm not sure if this is
> > > documented, desired, or whatever - i just found that out when I noticed
> > > i forgot to ->id, but it still worked.
> 
> I meant that
> 
> my $film = Film->retreive(1);
> my $actor = Actor->retreive(1);
> 
> Role->retreive(film => $film->id, actor => $actor->id) == # this works
> Role->retreive(film => $film, actor => $actor); # and so does this
> 
> Is the second way of doing this logically consistent?

I think so.


> 
> > I tried to run your test but do not have MySQL installed. From my
> > understanding, I think the inflation is a desired behavior (from the
> > Overloaded Operations section of the pod):
> > 
> >     When a Class::DBI object reference is used in a string context it
> >     will, by default, return the value of the primary key. (Composite
> >     primary key values will be separated by a slash).
> 
> But sometimes Class->columns(Stringify => 'foo_is_not_primary') is given
> which will stringify to something else.

Yes, I think that I see the problem. From my disjointed understanding of
the docs, we should always be calling $obj->id when requesting a primary
key. This means that some kind of function needs to be applied to force
has_a columns to call id() or else the stringified version will be
returned. The delete() function does this for single column primary keys
but fails to do so for multi-column keys. This works 95% of the time if
not using DBD::Pg (or other drivers that do not allow references) and
not stringifying.


> Also note, that has_a is inflated when stringifying - my script outputs
> 
> 	"Britney Spears/Kind of Blue"
> 
> when that link is stringified, and also sends
> 
> 	delete from links where artist="Britney Spears" and album="Kind of ABlue"
> 
> when I tell it that such commercialism was not yet popular in the
> 1950s. The primary key for $link is the two IDs - an album and an
> artist. Try looking at the source if I'm not sounding logical - I
> usually fail miserably in this respect...

This makes sense. Because you are stringifying, I can see where the
delete function which calls $self->id would pass in the stringified
version of the field instead of the id.


> > My problem is that DBD::Pg does not like to receive an object even if
> > calling it in scalar context will return a value.
> 
> Is it just passing it unstringified to XS?

Yes, I believe this is the case which is why DBD::Pg is complaining
about receiving a reference.


William

        -- 
        Knowmad Services Inc.
http://www.knowmad.com