Subject | Re: [firebird-php] [info/tip] dynamically created generators (inside stored procedures). |
---|---|
Author | Lester Caine |
Post date | 2006-02-23T16:50:49Z |
Jochem Maas wrote:
populating it with tables, and automatically building the triggers for
AUTO - along with 'fixed' generators used by the code for such things as
page_id and poll numbering.
The SQL standard refers to sequences now, ADOdb manages these using the
available underlying database - even creating a simple table if nothing
else exists :)
would cause a problem? If the generator can't be created for some reason
you can flag that? That is the approach that is used for polls. Each has
it's own generator. Even works without wrapping it in a transaction.
The code you had so much trouble with looks similar to that contained in
ADOdb - so since you had talked about not re-inventing the wheel .....
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
>>How about looking at how ADOdb does it then ?No - I've already been there ;)
>
> huh? did you read the rest of my post? I'll admit that adoDB is completely
> alien to me (I have my own custom firebird DB classes that I wrote with Ard - I think
> I posted them here once but one was interested :-)
>>bitweaver uses this to build the original database and add 'sequences'bitweaver will install from nothing and so creates the blank file before
> (what do you mean by 'original database' btw?)
populating it with tables, and automatically building the triggers for
AUTO - along with 'fixed' generators used by the code for such things as
page_id and poll numbering.
> 'sequences' are known as generators in firebird - not that this really important.I know - but
The SQL standard refers to sequences now, ADOdb manages these using the
available underlying database - even creating a simple table if nothing
else exists :)
> I'm not talking about creating a database and it's 'fixed' generators (andDon't see why creating the required generator THEN inserting the record
> relevant 'auto-inc'-like triggers) - by 'fixed' I mean that a table such as COMPANY
> would probably have it's own generator calld something like GEN_COMPANY_ID - such
> a generator doesn't need to be created on the fly.
>
> what I am talking about is created a generator on the fly as a reaction to the
> insertion of a record in a particular table (in my case each row represents a
> prizedraw and each prizedraw requires it's own generator, given that the client
> only starts creating 'prizedraws' after I deliver the app means I can't create
> the generators for the 'prizedraws' (pretty obvious given thgat the 'prizedraws'
> don't exist when I ship the app.) - another important thing to consider is atomicity:
> I want my record to be inserted and the generator created as one operation
> (therefore inserting the record and then letting php extension/code create the
> generator is not an option - and if it had been it would have been easy).
would cause a problem? If the generator can't be created for some reason
you can flag that? That is the approach that is used for polls. Each has
it's own generator. Even works without wrapping it in a transaction.
The code you had so much trouble with looks similar to that contained in
ADOdb - so since you had talked about not re-inventing the wheel .....
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.