[Webware-discuss] Some considerations for MiddleKit, Dumping data, Triggers, Transactions

[Ernesto Revilla]

Dear everybody,   Still I'm not using Webware. (But I hope soon.)   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 (MiddleKit transaction)    * 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 do this.)    * 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 class.attribute1.attribute2......attributeN=something, like 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, Erny Spain