Re: [PEPr] Comment on Database::DB_DataObject_Transaction

Bonjour, Thanks for your check, alan, I'm just unsure what you suggest, why I prefer to reply here before changing/removing the proposal. Alan Knowles wrote:

Alan Knowles (http://pear.php.net/user/alan_k) has commented on the proposal for Database::DB_DataObject_Transaction. Comment: I think it may be best to patch DataObjects to support some of this: function find($n == false,$opts=array()) .... if ($opts['lock_row']) { $query .- ' FOR UPDATE'; } .... Do you suggest to patch your package before install it ?

I agree that overwriting _query() is no good/possible way, is the onliest possible now. Right, it's only find() needing an extension. Could it be possible to have only a "free" SELECT extension as function find($n = false, $extend = '')

....             $sql .= $extend;
       $this->_query($sql);

.... but yes, for row locks, maybe some other syntax are required by not SQL handlers, so perhaps better to handle it precisely.

The rest of the package seems a little unrelated to transactions pardon ?

(more to do with sessionizing objects, yes, the "remember" part should be possible other way, it's not necessarly over HTTP.

I look forward to open customization on it. The target here, was to provide an easy (as DB_DO philosophy) way for common HTTP DB upgrades

and creating a mega insert/update/delete method.) The "mega" comes simply from the process, as you should be enable to change a row *only* if you requested it (and your "copy" is still valid)

Which to be reusable should not really extend dataobjects... (eg. something like $do = DB_DataObject_SessionCache::get('tablename',$somevalue); eg..) huh?

although you have to be really carefull when working this way, as the session may contain out of date data, after a few requests... That's the purpouse of the extension, secure updates, allowing them only if you requested it and you agree with what was there.

Yes, if using sessions, they should die with the connection. Really, the extension is nothing but has a real goal: 2 users/machines should never make an update the same time on the same record. Table lock is too heavy, can't work in production. Row lock ensures the atomicity of updates without locking the whole. Sorry for this very bad english a+ -- bertrand "toggg" Gugger >Proposal information: >http://pear.php.net/pepr/pepr-proposal-show.php?id=313 > > >