Re: ACID et al

x wrote:
> "paul c" <toledobythesea_at_oohay.ac> wrote in message
> news:zz_kf.47341$ki.41902_at_pd7tw2no...
>
>

>>>This looks like an optimistic lock, with the responsibility of enforcing
>>>it pushed to the application.

>>I'd prefer to say 'pushed to the client'.  An app with little need for
>>high concurrency could choose to let the messaging layer in the client
>>take care of remembering the previous message, even though that might
>>involve redundant work in the 'server' (only one message would need to
>>be 'remembered', so that kind of infrastructure ought to be fairly

Yes, I think you've nailed more or less what I meant. I once worked for a guy who said something like 'you always need an engine'. What he meant was that as soon as you start talking about 'client-server' (I use that phrase even though I'm uncomfortable with the way it often pins down our thinking unnecessarily), some form of the same engine has to exist on both sides if we want to have real simplicity at a level above, such as the programming api. Later I was fired for asking the arrogant president of the company "where's the engine?" but that didn't change my mind.

Somewhere I remember reading Hugh Darwen who put it in more useful way for me, something to the effect of "a db must have a language". For me that language would express some of the spirit of TTM. Whether it should express anything else is a problem I've been grappling with. It seems it must if any leverage (ie. re-inventing as few wheels as possible) is to be gotten out of existing environments (I'm thinking of typical www components such as the scripting in browsers for example).

However, a more significant problem seems to be that there is mismatch between the concept of a relation and the programming support in those existing environments. I say 'more significant' because it isn't tied to the technical details of one environment compared to another rather it is a difference at a deep conceptual level so a bad approach could have devasting effects on the programming simplicity or lack thereof.

cheers,
paul c. Received on Tue Dec 06 2005 - 16:38:04 CET