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
|