Jack Moffitt <[EMAIL PROTECTED]> wrote: > MiddleKit seems to be very easy when you don't to worry about the > database details. But when you have a storage system already in place > and need the middle objects, it doesn't really help.
Do you have to access that storage from different programs? If not then you could just transfer the information to the new (slightly different) database structure. Still, I've been reluctant to use MK myself because of this problem too. In part because the data (at least sometimes) is more valuable than the program. But the other part is I like the concept of a database as a means of abstraction and communication. Not only doesn't MK deal well with legacy databases, I don't think it would deal well at all with non-MK clients accessing and updating the database. At least that is my impression, as MK does a lot of caching. The database does caching itself, and personally I'd rather keep the caching flat -- caching at the Python level saves some communication overhead, and also caches what calculations occur to create the Python object (which should really be small anyway)... but if you are allowing multiple clients then that's going to kill any benefit of caching. I'd be curious just how much faster caching makes the database access in the current case. So, if MK is the moderator through which all requests have been made, is it as good a moderator as the database itself? It uses Python, which is nice, but maybe also not nice (if you ever have to use anything else). I'm not sure how well it would deal with all the potential data integrity problems -- these have taken databases a long time to resolve, and I think the entire work would have to be duplicated in MK to manage that integrity. Anyway, that's where I am myself. There's other similar things to MK, but most of them are lame dictionary interfaces (which capture the easy 90% of the problem, but just make the other 10% of SQL queries more awkward). I've looked at PyDO a little myself (it's part of SkunkWeb), but haven't come to any opinion. The author talks about some of these issues more or less in the intro to PyDO. In the end, I don't think the decision has to be made too firmly, if the *interface* of the objects you create is a good one -- be it with MK, PyDO, ad hoc, whatever. Then you could hopefully transfer it to something else. I've been thinking about how to shoehorn other document styles into Cheetah, and I realized that's dumb -- Cheetah doesn't have to support everything, but Cheetah exposes a certain interface and the interface I create for other documents should just match that. The same thing might make sense for legacy databases and MK. You don't have to use MK, you can just make something that looks like MK. Maybe there's also portions of MK that you can still use, just not the package as a whole. I've had the idea of my own wrapper in my head myself for a while -- but then I've had lots of ideas in my head, and that doesn't necessarily mean much. It's a hard problem. Ian _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
