At 11:21 PM 10/17/2001 -0600, Jack Moffitt wrote: > > 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. > >I'd like to hear Chuck's comments on this too. Chuck, (or others who >are using MK), are you using the data without MK often? And if so how >does that work?
MK will cache lists and such, but in practice I often refetch objects from the database because they may be modified by outside programs (in one project, another MK based program (though not a web site)). And this is a general problem with SQL databases. While you could probably cook up some kind of change-notification scheme using triggers and a notification process that implements a subscription type service (ahem, just discussed that with a friend last night), I haven't seen this inherent in any DBs. Therefore, it's inconvenient and expensive to build. Of course, you can tell I'm thinking about trying to work this into MK for the benefit of MK apps. :-) But it will be while before I can take a whack at it. In direct answer to your question, yes I have projects where multiple clients hit the database, but no they are all MK. (Unless you count the MySQL GUI that I sometimes use to fix things up.) Again, if you want to use MK, but avoid a SQL schema that other products will balk at, refrain from using the obj ref and list data types. That puts you back at using explicit foreign keys like ints and strings which you then have to provide for. But then you have to do that somehow whether you use MK or not, so it's not as if MK caused you more work. You might say then that MK didn't give you much, but then I say it gave you some things and that it's a platform on which we can continue to build good stuff on. Object models are your friends. Someone else wrote: > > 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. I think many web apps including my own could realize a big performance gain if they only had to fetch objects that changed. I'd really like to see databases allow clients to listen for this info, or a solution that effects the same thing but as an add-on/tool. Of course, the pay off will vary immensely depending upon the application. >I think there are at least two purposes here that are possible mixed up >in MiddleKit. > >One purpose is making database stuff easier. It certainly seems much >easier to do stuff with MiddleKit than the manual way. Chuck has done a >great job in this regard. Thanks. :-) >Another purpose is managing these middle objects. In java, these are >often managed in their own environment, usually implement RMI, and can >be distributed, etc. There's a lot more emphasis on caching, and how >many copies are running, etc, and much less on making data access easier >with the backend storage. > >I think MiddleKit just does both of these together, and I'm wondering if >there's an easy way to seperate the functionality, so that I use my own >storage stuff, but keep similar interfaces for the upper layer. Actually MK does nothing in terms of distributing your objects as independent services accessed via TCP/IP. More often than not, I don't need that in a project, so it wasn't a focus. Actually I have never needed that. BTW I find MK's object model increasingly useful for other tasks including generating views, generating forms, and traversing the class hierarchy for various purposes. For a partial example of this, look at the hardly-maintained MKBrowser, which can browser any MK repository using generic algorithms that work off the object model. Also, I barely touch on this in one of the manuals. In the future, I picture loosening up the SQL bent than MK has so that you can easily use MK without getting generated SQL code or requiring a SQL database, if you're not interested in one. >I supposed I should just read through the code and see if I have any >ideas. > >If I wasn't so used to the php/mysql/perl/blah way of doing web apps I >probably would have used MiddleKit right off the bat. I may recode it >to use that.. it certainly seems nicer. But for other things were the >data might be shared, like this directory, I just need the middle layer >without being so tied to the storage. But what do you want out of the middle layer? For starters, I'll assume Pythonic objects that do something useful for you in the background. Does that include automated storage to LDAP? Does it also include some kind of IPC access on an object and method level? -Chuck _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
