Re: Need help with finding solution to CDBI bug

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

--On Friday, June 25, 2004 5:33 PM +0100 Tony Bowden 
<tony-cdbitalk@xxxxx.xxx> wrote:

> On Fri, Jun 25, 2004 at 12:12:11PM -0400, Charles Bailey wrote:
>> 0. CDBI's goal is to present an object-based interface to a data store,
>
> Actually, I'm not sure I'd quite agree with this. Class::DBI's job is
> to make working with databases easier. It attempts to remove much of the
> tedium from writing the same types of queries over and over again, whilst
> also making it possible to construct and execute arbitrary SQL statements
> when you need to. Most of the rest is really just an attempt to provide
> a smooth curve between these points, so that users aren't faced with a
> system that makes the easy stuff simple, and the hard stuff impossible,
> or that makes everything as kludgy as hell.
>
> It happens to do this through a mostly-OO style approach, as it fits quite
> nicely, but of course we're living at the intersection of data-driven
> programming and object oriented programming and usually being a hybrid
> that proponents of both methods scorn.

Fair enough.  It's a compliment to CDBI, then, that I've been able to 
insulate application-level code sufficiently from the details of the DBMS 
that I can think of it as an object-based wrapper.

I'm not educated enough nor evangelical enough to qualify as an OO purist; 
it's just nice that I can write a layer between the DB and the application 
that cleans up the data, handles defaults, and buries the grunt work.

>> (As an implementation detail, the data store happens to be a relational
>> DB with a SQL-driven interface, but CDBI's trying to insulate the user
>> from that.  It does make available ways to execute custom SQL queries,
>> but even there tries to insulate the user from the details of the SQL.)
>
> That I definitely don't agree with. Users of Class::DBI should always
> be aware that they're dealing with a database. We're not trying to hide
> that. A lot of stuff doesn't make sense if you remove that context.

I'm not trying to argue that the database is hidden, just that details are 
hidden.  People will, of course, need to be aware of the types of 
information it can hold, and enough of the schema to make sense of a 
table-based class.  That said, one of the nice things about has_a 
relationships that aren't just joins to other CDBI classes is that the 
outside world doesn't need to know about how a particular datum is stored 
in the DB, it just needs to know there's a (say) Time::Piece it can operate 
on.

>> 1. id() is a shortcut accessor which returns the values of the primary
>> key  attributes.
>
> Almost. id() is a unique identifier for the instance. As we're dealing
> with a database this will represnet the value be the primary key.
>
>> 2. Therefore id() should return a collection comprising what the
>> attribute-specific accessors for each component of the primary key would
>> return.
>
> I think rather than id() should return whatever you would pass to retrieve
> to re-instantiate the object.
>
> I know that id() doesn't currently do that for MCPKs, but I'm speaking
> philosophically here rather than practically. (This of course raises the

Interesting - that's a third perspective I hadn't thought through.  It 
might be sufficient to just make retrieve() a bit smarter -- it knows how 
many columns are in the PK, so if it sees N args, it could assume they were 
values in the column order returned by primary_columns(), while if it sees 
2N args, it could assume they were colname => value pairs.

> point that in all this stuff I may be completely wrong. Don't take any
> of this as a Grand Pronouncement on the state of Class::DBI. Mostly I'm
> just making this up as I go along)

Again, fair enough.  If enough people think there's a use for an 
object-level analogue, I'm happy to submit a patch for key().  If not, I 
can just drop it into the local base class here.

>>  If the class has redefined the Stringify group, things break.
>
> Yes. This is another problem with the current implementation.

Sure - without this, the id() issue wouldn't have arisen.

>> Limiting id() to just db-level information fixes the problem, but
>> seems like swatting a fly with a sledge.
>
> I'm assuming you lost a hammer somewhere there, but it's an interesting
> image anyway :)

Wups - brain left fingers behind.  It does satisfy the requirement of an 
extreme case, though. :)

--
Regards,
Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
Newman Center at the University of Pennsylvania