Re: Unknown SQL

(removed comp.lang.java.programmer from recipients because of complaints)

Joe Cosby wrote:
> >There is one exception here:
> >Statements for mass updates have no means to resolve locking conflicts.
>
> That doesn't really have anything to do with knowing or not knowing
> SQL, it's just something that bothers you about SQL.
>
> And it is an implementation issue.
>
> It would be SQL's job to provide a language to phrase the desired
> transaction to the database system with. It's the underlying
> database's job to handle concurrency.

I would find it nice if the involved objects themselves would be notified about concurrency problems. They could take measures to solve the problems. Depending on the objects and the priority of processes, solutions might be very different:

• allow overwrite
• discard changes
• reread objects and rerun business logic
• forward the problematic objects to a human

I would want more flexibility than "throw an exception during commit if something is wrong".

The impossibility to provide such a solution arises out of the usage of SQL because the database interface is moved away from objects.

> The idea of an abstract language like SQL is to remove underlying
> issues like that from the programmer.

SQL is great for quick-hack-querying and quick-hack-updates. SQL is not nice for providing solutions for complex concurrency problems.

The first posting to this thread "S.O.D.A." comes from the desire to create a query API beneath SQL that uses objects only.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com