Jeff Moore wrote:
> On May 25, 2004, at 12:09 PM, Rob Hoopman wrote:
>> Unless you really mean "get the primary key for the last insert", but
>> that's a different kettle of fish.
> YES! That is exactly what I mean. :)
If that's the case then be sure to make it very obvious by reflecting
this in the method name. Otherwise you're going to end up having to
explain this behaviour to every that comes to WACT.
> It seems like all of the databases have the ability to have an
> auto_increment/serial column. So what I want to automate inside the
> insert() function is the operation:
> insert a record into a table with a primary key represented by a
> auto_increment/serial column and return the primary key of the inserted
> I am open to splitting this into its own function. Perhaps insert() and
> insertAndReturnPrimaryKey() (help me with the name). I am beginning to
-------------------------- At least that's clear.
But, to play devils advocate, what happens with multi-column primary
keys? Should return an array?
an't speak for other backends, for postgresql you'd need to hit the
backend twice, once for the insert and once to get the primary for the
OID just inserted. So it would be nice to have a way to suppress
I imagine other backends would need to do the same, at least for
multi-column primary keys.
> think that splitting this off would be a good idea.
If you're after this behaviour, I think it might make sense. But you'd
be nuts trust my judgement after playing with WACT for a couple of days ;-).
> I assume this is enough to
> establish an naming convention to match up to a sequence. Is this wrong?
Can't image where you'd be wrong.
> On May 25, 2004, at 10:29 AM, Lorenzo Alberton wrote:
>> Basing on my experience with DBAL systems, I'd go for
>> the DB/MDB/MDB2 way of doing it, because it has proven
>> to be quite solid and works for every dbms.
> The problem I have with the create a sequence/ generate id / insert
> record with idea method is that it ends up messy in mysql. it creates
> extra sequence tables which aren't strictly necessary in that driver.
I have little experience with MySQL, but that implies there's no way to
ask MySQL for an available id for the next insert?
> I don't see the two approaches as incompatible and suspect we will
> eventually implement both anyway.
> take a look at:
> adodb/DB/MDB/MDB2 all have a very similar interface for accessing their
> features. I have no desire to create another DBAL matching the same
> interface. I also don't necessarily think the structure of these
> drivers is the last word on DBALs.
> I also don't think it makes sense to have an abstraction layer for
> abstraction layers.
I was wondering about this,..
> Does it make sense to be able to configure your
> program to use adodb or MDB2 at runtime? I think not. People who want
> to use a mature DBAL with WACT should just pick ONE and use the WACT
> driver for it. There is nothing wrong with peeking into the WACT driver
> to call pear:DB functions in a application. An application that does so
> is still abstracted. The DBAL adapter drivers right now are not set up
> to make this easy, but that could change. For example, there is no
> reason why the Connection class in the driver couldn't just inherit from
> the connection class of the DBAL it wraps instead of keeping an
> instance. That would remove a layer of indirection. The drivers could
> also keep the instance variable and pass through more of the DBALs methods.
What would be the drawbacks of this? Just inheret from the DBAL,
override the connection methods, and leave the rest of the DBAL exposed.
Or would you end up having to override a lot of methods anyway for
functionality used by the framework?
Or, settle on one DBAL. I am used to ADOdb myself, but could care less
if it's ADOdb, MDB, propel or whatever doing the work while I am
interacting with WACT objects.
And for anyone who feels particularly religious about the subject it
shouldn't be to hard to do their own DB interaction and pass the results
> So why have native WACT drivers at all? Well, I don't think the
> existing DBAL interfaces are the last word on the topic. The WACT
> native drivers are meant to be an experimental interface, to advance the
> topic. I specifically don't want them to be like the other DBALs. If
> they were, I think it would be a waste of time working on them. Does
> that make any sense?
> Anyway, the auto_increment primary id column was one area where I
> thought it might be possible to gain some ground. sorry for the
> philosophical interlude. :)
For me, ADOdb does what I need it to do. OTOH there is always room for
Allthough developing WACT _and_ developing another DBAL and keeping bth
projects moving might be a bit much...
> On May 25, 2004, at 12:09 PM, Rob Hoopman wrote:
>> I'm wondering what will the return value for insert() should when the
>> sequence column is defined in $fields?
> Do you have any suggestions?
Whatever you do, do *not* drop it (the column) on the floor. If you feel
strongly about preventing unsuspecting users shooting themselves in the
foot; Return FALSE and raise an error, but add a flag to override this
behaviour and insert anyway.
I would say just insert it, I hate being second guessed ;-). Raising a
warning for use in debugging might be useful.
At some point you're going to have to trust the developer using your
code knows what he is doing...
P.S. Is anyone else having problems with anon CVS today? I hate it when
sf does that.
Yeah I know; gift horse and all that....