Re: DB_DataObject and PostgreSQL

Demian Turner wrote:

Hi What exactly do you want to know? Most of these things (like foreign keys and triggers) are handled transparantly by the DB. You don't fire them explicitly, so they work just the same no matter what client you mainly - how DataObject would respond to a failed referential integrity check - executing stored procs and transactions from DO, thanks Alan - integrating triggers, like the following: CREATE TRIGGER log_update AFTER UPDATE OR INSERT

    ON userinfo FOR EACH ROW
    EXECUTE PROCEDURE log_update()

This will work, any query or function that fails will (or should at least) trigger a PEAR errorm, regardless whether it is q query directly sent or a query resulting from a trigger/function. Some for errors caused by contraints such as foreign keys.

(taken from this month's php|architect) I realise this happens at the DB level, independent of DO, was curious if anyone had attempted something similar with success? I'm using postgresql with all the features you mentioned and it did work well with DO, but I found that postgresql and dataobjects have some overlap. By using (foreign key) constraints and views and stored procedures you no longer need to automatically link tables using DO or supercomplicated queries. I also used some transaction and using DO turned out not to be that handy anymore. So I actually went from using Postgres and DO to just using Postgresql and PEAR::DB for one particular project. For other projects though I really like DO, especially for tables with a lot of fields.

Just my 2 cents. Jeroen