Re: chooses not to generate code at all

Responding to Frebe...

What do you use instead of queries? 

If it is an OO application I would use direct relationship navigation to
the object with the data from the method needing the data.



Lets say we have a planning application with a event class as follow:
class Event
   property resourceid
   property starttime
   property endtime

Now I have a client that want to show all events in a graphical view
for one resource during one week. I would find the events using this
SQL query:

select * from event
where resourceid=? and ((starttime between ? and ?) or (endtime between
? and ?))

How would your solution look like? 

You have

         1     R1      *
[Client] --------------- [Event]

The client would "walk" the relationship. In an abstract action language that would look something like

refSet = this -> R1 WHERE (starttime > ? AND ...)

However, this is a straw man because the example is so simple that superficially they look the same. The real issue lies in things like joins. The real power of DBMS queries lies in accessing aggregates from multiple tables. In the OO application context one would never have such complexity since (a) methods are simple so they have simple data needs and (b) knowledge is accessed on a 1:1, peer-to-peer basis rather than as multi-object aggregates.

The point is that one does not need persistence to do <business>
transaction processing.


That's why you would still need a DBMS event if you don't need
persistence.

You are arguing that even though DBMSes came long after the transaction processing paradigm (and, in fact, the DBMS paradigm can be argued to be a specific implementation of that paradigm) that somehow transaction processing is a uniquely DBMS feature.

A transaction at the application level is
nothing more that a message {message ID, address, data packet}


For me a transaction is a number of state changes. If one state change
failes, the rest of them has to be cancelled too.

This confuses the data and referential integrity requirements implicit in transaction processing with a specific implementation of those requirements (i.e., the DBMS engine view). There are other ways to deal with the problem (e.g., reversing the transactions up to that point rather than cancellation).

Also note that transaction processing is quite feasible and commonly done by "posting" one transaction at a time, in which case the data integrity constraint you are citing is not an issue. It only becomes an issue when one "batches" transactions at the client level into large update queries. And that is done primarily because of performance issues in accessing the DBMS. (The one-at-a-time approach is more natural for applications because of the nature of 3GL iteration constructs.)

Nor does one need a DBMS to handle persistence in <business> transaction
processing.


Other simpler tools can handle persistence in business transaction
processing. But a DBMS would be a better choice. What tool would you
use for persistence handling in business transactions?

You are pulling individual sentences out of context and attacking them out of context. I never said that DBMSes were not useful tools. They are very useful for data storage, especially in a transaction processing environment. That's because they are designed at least in part for that environment. But DBMSes didn't invent transaction processing and there are other alternatives for storage with transaction processing that were used for decades before DBMSes. The quoted sentence is simply making the last point within the overall context.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.