Re: database abstraction layer

Rene Veerman wrote:

On Wed, Feb 3, 2010 at 12:35 AM, Ashley Sheridan <ash@ashleysheridan.co.uk>wrote:

It's the reason transactions exist, to prevent things happening like this. When you have two actions where one is dependent on the other, unless you have a way to tie them together so that they can't be broken, you run the risk of collisions.

Yea, and i wish they'd standarized features like that across sql servers. But they haven't, so i avoid them like the plague.

This is why you're creating your own layer... to smooth the wrinkles between the systems via your abstracted layer. That isn't usually a good reason for you to do it improperly.

Whatever dependencies and threading problems might arise, there's always the principle that says: If it doesn't work whlie it should work and threading-timing problems are the only possible cause, then by delay by a random timeperiod and retry the query.

Yikes, please cite your reference for that horrible advice.

In really advanced cases, one can work with last-modified timestamps and/or build up a simple sort of work-queue (also in a table), whereby threads inform each other of the status of their computations.

Wow... this gets ever more complex to do something simple. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP