Lester Caine wrote:

> Jochem Maas wrote:
>
>
>>I don't consider what I built as re-inventing the wheel. I also think (in far as I
>>can tell from your description) that my implementation is technically better than the adoDB
>>implementation (granted that the adoDB implementation is generic andf mine is bound to
>>a specific table in my DB) because mine garantees atomicity where as the adoDB one
>>does not (it can't given that it's a 2 stage process that occur in different places, namely
>>inside the firebird process and inside the php process).
>
> It is just a different approach to a similar problem. As always there
> are many ways of doing the same thing. ADOdb has three different methods

microsoft has three different ways to do everything. ;-)

> of doing this, and yes it is database agnostic.

I've been reading:
http://www.firstsql.com/dbdebunk/

personally I have always leaned away from db abstraction.
in this case, I want to use firebird's features straight up.
on top of which for me a database is quite abstract enough as it is ;->

shouldn't SQL be _the_ abstraction layer? think about it for a while :-)

if database -connection, -authentication & -authorization are platform specific
I don't see that as an issue but data access should be universal
(in so far that given a single _complete_ language [an SQL replacement that will
probably be called SQL ;-)] would be adhered to by all, I could imagine defined
subsets of the functionality to be implementable - whereby all DBMS support
parts of single common ground, as opposed to lots of different 'flavors' of SQL,
with disparate syntax and capabilities)

>
>
>>for instance what happens if you succesfully create the generator then the insert fails?
>>then you have to remove the generator, right? what if that fails? - I'd rather
>>let firebird sort that out.
>
> Actually the bitweaver approach would establish the next 'prizedraw'
> number, create an entry for that, create the matching generator and any
> other secondary table entries to go with that, and THEN commit the data.
> Rolling back if a problem prevents any stage. In the early days I had a

indeed use a transaction - but it still means this logic is in php, meaning
that alternative interfaces to the db _must_ replicate the logic.
(not doing so would damage the integrity of data.)

> problem preventing code working because Firebird WAS rolling back
> properly - I just did not know it :(

ouch.

I really wanted to take a look a bitweaver - Im interested how it would go about
solving the 'gimme a prizedraw management tool' question that I got put to me,
as in how much and what kind of code would I need to write in order create the custom
app (assuming I already had a 'site' running for the given client i.e. stuff like
page layout, base functionality, etc is taken care of)

..but the site is down ... heh its up again ... i'll go take a proper look in
a minute ...

another thing is how little time/energy does it cost to produce a sophisticated
'data management' interface (i.e. good CRUD :-) for a given 'data entity'?
(sophisticated is relative ofcourse and not being able to show you
doesn't help)

for my prize draw it took basically the following (there is an additional class
for the 'Prizedrawcode') (obviously there is a framework of some sort in place ;-) :

class Prizedraw extends Persistent
{
const TABLE_NAME = 'LC_PRIZEDRAW';

/* constructor */
/*
public function __construct()
{
parent::__construct();
}
*/


/* returns the array of field objects this class contains */
public function getFieldList()
{
static $result;

if (!$result) {
$result = array (
'LC_PRIZEDRAW_ID' => new GeneratedKeyField('LC_PRIZEDRAW_ID', '', Field::INTEGER, 0, true, true),
'WEBCODE' => new RealField('WEBCODE', '', Field::VARCHAR, 32, true, true, null),
'NAME' => new RealField('NAME', '', Field::VARCHAR, 128, true, true, null),
'START_NUMBER' => new RealField('START_NUMBER', '', Field::INTEGER, 0, true, true),
'ACTIVATED' => new BooleanField('ACTIVATED', '', true, true),
'DEACTIVATION_DATE' => new RealField('DEACTIVATION_DATE', '', Field::DATE, 0, true, true),
'DRAWDATE' => new RealField('DRAWDATE', '', Field::DATE, 0, true, true),

'PAGETITLE' => new RealField('PAGETITLE', '', Field::VARCHAR, 128, true, true),
'IMAGE_ID' => new ReferenceField('IMAGE_ID', '', Field::NULLABLE | Field::INTEGER,
'Image', false, true),
'HTMLCONTENT' => new RealField('HTMLCONTENT', '', Field::TEXT, 0),
'THANKYOU_HTMLCONTENT' => new RealField('THANKYOU_HTMLCONTENT', '', Field::TEXT, 0),

'PRIZEDRAW_CODES' => new VectorField('PRIZEDRAW_CODES', '', 'Prizedrawcode',
array('LC_PRIZEDRAW_ID')),
);
}

return Persistent::cloneFields($result);
}

/* returns the generator that is used to invent new IDs for this class */
public function getGenerator()
{
return 'GEN_SWEEP_ID';
}

/* returns the name of the table containing objects of this type */
public function getTableName()
{
return self::TABLE_NAME;
}
}

>
> You have posted to the php list, but actually your 'discussion' is

actually firebird-php list; so I'm 50% on topic ;-)

> really one for support, since there is actually no php involved anyway ;)

this is the only firebird list I'm on, are there others (not in russian ;-)
ok. now off to bitweaver as penance. :-)