Still I'm not using Webware. (But I hope
Things that would be nice:
* The dumping routine you (Stefan and Jason) should
be part of MiddleKit and perhaps the default persistence method, if no database
is configured. Consider the Java J2EE container behaviour which writes entity
beans to files when it is shut down.
* An model-wide unique object Id. I read in an
article of OR-Mapper (I think the author was Scott Amber) the advantages of
unique Ids. One could be replication (security, load-balancing, distributed
applications). Others could be indexing, referencing, etc and of course dumping
down all the MK data and reloadind it later (no need to change any object
references). Like the sequecences, counters or autonums of databases, the could
be a 64-bit number splitted in two parts x-y. X will be fixed for an
application which generates new numbers y. Whenever an application requests for
generating new autonums, it asks a central server which distributes the x. When
all y numbers are used, it'll request a new x from the server. No database
specific function will be needed. Of course, instead of a 64-bit long, you could
also use strings or other encondings.
* Transactions: In Webkit a transaction
is a container for session, request, response and others. I would like to see
the interest of MiddleKit object manipulation transactions, like change this,
change that, and if it fails rollback. In contrast to Webkit Transaction, a
Middlekit Transaction could live during a whole session, not only for a request.
Perhaps we could call it 'MKT'. I thought about this and found that perhaps it
could be accomplished using the following technique:
* Set some flag to start a MKT
* Whenever I change an attribute, look
if there is a clone in the session of the object to change, else clone the
original object and store it in the session.
* Whenever I read an attribute of
a object and I'm inside a MKT, lookup if there exists a object clone in the
session. If it exists, call the accessor method of the object, otherwise
the value of the normal request object
* If changes are commited, substitute
the old versions of modified objects, with the new ones. (Don't know how to
* On Rollback, simply delete all MK
Objects (Klass) from the session.
* Triggers: It seems that a database abtraction
layer gives us the freedom to choose whatever database vendor. Compiere ERP (see
Sourceforge) is using oracle but a PostgresSQL transformation is underway. But
no database abstraction (but translation). So we hace to rewrite all the logic
again for the middle-tier? Don't know. Perhaps. In the object world, triggers
are observers. Whenever a observer wants to see changes (or accesses) of an
object (class) it registers itself in the class. Whenever a value is changed
(setAttribute) it checks if there are any observers and calls them in sequence.
An observer could change the real value to be changed (or leave it as it is,
cancelling the modifications).
* As I have the plan to write a ERP, I will try
also to write some rule interpreter, so business rules can be written in a
simple language: If attribute x of an object of class y is modified, change,
delete or insert a object, or call some other function. (It would be nice, that
advanced users of the application could establish their own rules: if stock goes
below stock.min, send me an email.)
* I don't like where much SQL conditions as it
binds to much to the database. Instead a generic query language should be
established, perhaps a subset of OQL. Instead of TableX INNER JOIN TableY INNER
JOIN TableZ, much more intuitive and easier to remember and write would be
Order.Line.ArticleRef.Stock<1 should be translated into SQL (ArticleRef is of
type Article, Line is of type OrderLine) to (Article INNER JOIN OrderLine ON
Article.Ref=OrderLine.ArticleRef) INNER JOIN Order ON
OrderLine.OrderRef=Order.Ref WHERE Article.Stock<1). Also object comparison,
should have no problems if unique Object-Ids would be used.
With best regards,