Re: Updated Limit Patch for C::DBI & C::DBI::MySQL

[prev] [thread] [next] [Date index for 2004/07/28]

>
> Is there something more generic we're missing here?

well, what we have that probably doesn't need to change is the hash of 
search options.  That public part of the interface is slick and 
intuitive.  If you have stuff to add, throw it in there.

Maybe what C::DBI needs is some intermediate format for SQL statements, 
so that subclasses can get their $.02 added in before it gets executed.

For example, if we had

SELECT
	__ESSENTIAL__
FROM
	__TABLE__
WHERE
	Name = ?
[
ORDER BY
	Name DESC
]
[
LIMIT 2, 5
]

then we could have some sort of structure like this:

{
	base => 'SELECT
	__ESSENTIAL__
FROM
	__TABLE__
WHERE
	Name = ?',
	order_by	=> 'ORDER BY
	Name DESC',
	limit	=> 'LIMIT 2, 5',
	other_db_specific_feature
}

and then it could be up to the implementer to put them in the right 
order, which for mysql would be base, order_by, limit

just my $.02.  Either way, though, with little stubs there is more work 
in C::DBI, or with putting together SQL in the subclasses the bulk of 
the work moves there.

Wait, i had another idea.

What if there was one _search_options function that the subclasses 
could override.  That would be responsible for dealing with the DB 
specific stuff, and C::DBI would just call that, using it's own if it 
isn't subclassed, and limiting it to the basic order_by functionality.

Sorry this is so long.  Typing out loud.



-jason scott gessner
     jason@xxxxxxxx.xxxxx Jul 28, 2004, at 11:38 AM, Tony Bowden wrote: