Sean Legassick wrote:
>
> On Tue, Jun 27, 2000 at 03:47:41PM -0700, Daniel L. Rall wrote:
> > I understand that, and am saying that it's yucky when every adapter must
> > stub out a method that is a workaround for or applies to only one
> > database.
>
> They don't have to - DB is an abstract class not an interface now, so DB
> can implement the "normal" behaviour, and the adaptor for the database
> that needs the workaround can implement the "weird" behaviour. No other
> adaptor class needs to be affected.
Good point, and "the right way" to do it.
It still doesn't change the fact that the MySQL adapter, for instance,
will
have transaction-specific methods in it for which it has no support
(even if
they do nothing). Could another abstract class that extends DB be
created
into which all transaction-specific [or fill in your db-specific
feature]
interfaces could go? This would probably mean mucking w/ BasePeer, but
it
would mean a hell of a lot less mucking. :)
--
Daniel Rall <[EMAIL PROTECTED]>
http://collab.net/ | open source | do the right thing
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
