Nico Klasens wrote: > 1 User layer - thiu layer is user-centric and every action is based on > this user, his role and the security constraints. You could say this is > the bridge, because the cloud has a user and it applies the securtiy > constriants > 2 Repository layer. This layer is used by all users and exposes all that > is in the repository. This layer maintains the model: builders, > typedefs, reldefs typerels oaliases, etc. Data which is in this layer > can be seen by all users. Data in the User layer can be specific for > that user (local modification). > 3 Storage layer. This layer is responsible for pesistence and retrieval > of data. The repository layer uses this to store and retrieve nodes. > This layer decides how and when to interact with the persistent store > (database). It could use a cache instead of the trip to the persistent > store. > > At the moment, the processors are called in the bridge which is > user-centric. A procesor should work just for one user and one request. > The loop example is executed for in one request and could be a local > modification until it is saved to the repository layer (this is what a > transaction does).
What my processors actually did was simply having a small static storage in memory for those fields, and simply translate every change in 'don't change it', and checks it on every get. One can find that an odd location, but it is rather pragmatic, because it is shallow, and easy to implement. I think that whay you say can actually be interpreted as that the current loop in DatabaseStorageManager#change(MMObjectNode, MMObjectBuilder), to check if there are changed fields, is wrong in the first place, and the 'change' method should not have been called at all then, and that you could more easily agree if I moved the check from there to MMObjectNode itself to make getChanged ignore these kind of bogus-changes. Correct? > IMO it is a quick fix, because it solves somthing in the wrong position > of the system When it is really desired to delay the database call then > the storage layer should make this decision. The processors are just to > high on the chain to be able to make a good decision. With MMbase we try > to reduce the load on the database, because mmbase can easily create a > starvation on database resources. But I don't think this is the database > killing example. It is more the many small select statements which use a > new db connection which kill the database. This update example is just > being nice for mmbase itself (caches and events). We cache db-connections, don't we? Michiel -- Michiel Meeuwissen mihxil' Peperbus 107 MediaPark H'sum []() +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
