webware-discuss

I have not had a lot of time to poke around in MiddleKit, but I like what I
have seen already very much.
My biggest reservations so far are:
(1) The MiddleKit data dictionary does not seem to contain the detail (e.g.
primary key and foreign key constraints) that some apps would need, and
(2) The data dictionary organization is not relational, which makes it a
lot of work to maintain. The way that I have done it in my apps is to make
the data dictionary a relational database consisting of tab-delimited text
files, which - like MiddleKit's csv files - are easily edited in a
spreadsheet.
It would seem to make sense to have MiddleKit talking to ODBC as soon as
possible. It would also be nice to have it talking to Gadfly. If it does
not entail too much low-level wizardry, and if I can figure out what in
MiddleKit must be hacked, I would be willing try cooking up ODBC and Gadfly
adaptations.
Jim Dukarm
DELTA-X RESEARCH

At 04:39 PM 3/9/2001 -0800, J.J. Dukarm wrote:
>I have not had a lot of time to poke around in MiddleKit, but I like what I
>have seen already very much.
>
>My biggest reservations so far are:
>(1) The MiddleKit data dictionary does not seem to contain the detail (e.g.
>primary key and foreign key constraints) that some apps would need, and
The MSSQL adapter guy is working on this. Don't really have a time frame.
Maybe the next week or two.
>(2) The data dictionary organization is not relational, which makes it a
>lot of work to maintain. The way that I have done it in my apps is to make
>the data dictionary a relational database consisting of tab-delimited text
>files, which - like MiddleKit's csv files - are easily edited in a
>spreadsheet.
It seems our approach then shares using CSV files. MK's file however is
meant to be an object model, not a relational model. And to use Pythonic
terminology as much as possible.
>It would seem to make sense to have MiddleKit talking to ODBC as soon as
>possible. It would also be nice to have it talking to Gadfly. If it does
>not entail too much low-level wizardry, and if I can figure out what in
>MiddleKit must be hacked, I would be willing try cooking up ODBC and Gadfly
>adaptations.
MSSQL (which actually needs some fixing) already uses mxODBC which is DB
API 2.0 compliant, which is what the SQL adapters are based on.
A Gadfly adapter would definitely be interesting.
-Chuck

On Friday 09 March 2001 16:39, J.J. Dukarm wrote:
>>I have not had a lot of time to poke around in MiddleKit, but I like wh=
at I
>>have seen already very much.
>>
>>My biggest reservations so far are:
>>(1) The MiddleKit data dictionary does not seem to contain the detail (=
e.g.
>>primary key and foreign key constraints) that some apps would need, and
>>(2) The data dictionary organization is not relational, which makes it =
a
>>lot of work to maintain. The way that I have done it in my apps is to m=
ake
>>the data dictionary a relational database consisting of tab-delimited t=
ext
>>files, which - like MiddleKit's csv files - are easily edited in a
>>spreadsheet.
=A0i feel that having the integration of multiple data sources is more ke=
y than=20
a full or mapping tool. or tools are nice for simple cases but when you=20
actual use a rdbms to create a large relational system with multiple fori=
egn=20
keys, stored procs, etc, you're almost always better off and writing the =
sql=20
queries yourself. most or tools just run into land mines when they try an=
d=20
deal with this type of thing, if they even try to map the relations and=20
objects natively to the rdbms (as opposed to using some tables for bookee=
ping=20
the class metadata and relations). things like maintaining foriegn key=20
relationships properly in the face of new additions or deletions can quic=
kly=20
become a headache. i think middlekit would be better served as an integra=
tion=20
tool for multiple store persistence than a trying to go all out full or=20
mapping.=20
i'm going to shutup about middlekit for now till i understand the nooks a=
nd=20
cranny of the code, but i am interested in seeing what people want from=20
middlekit and what they feel its goals should be.
kapil

On Sunday 11 March 2001 04:11, ender wrote:
>>On Friday 09 March 2001 16:39, J.J. Dukarm wrote:
>>>>I have not had a lot of time to poke around in MiddleKit, but I like =
what
>>>> I have seen already very much.
>>>>
>>>>My biggest reservations so far are:
>>>>(1) The MiddleKit data dictionary does not seem to contain the detail
>>>> (e.g. primary key and foreign key constraints) that some apps would
>>>> need, and (2) The data dictionary organization is not relational, wh=
ich
>>>> makes it a lot of work to maintain. The way that I have done it in m=
y
>>>> apps is to make the data dictionary a relational database consisting=
of
>>>> tab-delimited text files, which - like MiddleKit's csv files - are
>>>> easily edited in a spreadsheet.
>>
>>=A0i feel that having the integration of multiple data sources is more =
key
>> than a full or mapping tool. or tools are nice for simple cases but wh=
en
>> you actual use a rdbms to create a large relational system with multip=
le
>> foriegn keys, stored procs, etc, you're almost always better off and
>> writing the sql queries yourself. most or tools just run into land min=
es
>> when they try and deal with this type of thing, if they even try to ma=
p
>> the relations and objects natively to the rdbms (as opposed to using s=
ome
>> tables for bookeeping the class metadata and relations). things like
>> maintaining foriegn key relationships properly in the face of new
>> additions or deletions can quickly become a headache. i think middleki=
t
>> would be better served as an integration tool for multiple store
>> persistence than a trying to go all out full or mapping.
>>
>>i'm going to shutup about middlekit for now till i understand the nooks=
and
>>cranny of the code, but i am interested in seeing what people want from
>>middlekit and what they feel its goals should be.
changed my mind, understanding the foriegn key structure is actually goin=
g to=20
be key if middlekit is going to be talking to existing dbs... but i'm not=
=20
sure about how best this could be implemented. how do you inserts/propoga=
te=20
errors when you try to delete/update/insert into tables with lots of not =
null=20
foriegn keys.
this also brings up problems in terms of getting into rdbms specifity aga=
in,=20
dbs like oracle can lock up if you don't properly index foriegn keys, and=
=20
insertions are performed in certain orders. for an example check out
http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg_id=3D000KOh
if at all possible though keeping to sql92 standards should be attempted,=
not=20
using vendor specific logic is a good thing.
in the end, its probably best to keep the or layer simple and db agnostic=
so=20
that middlekit can be used with multiple dbs.
the use of other persistence stores should be unaffected as long as rdbms=
=20
stuff is kept specific to sqlobjectstore and generators and doesn't make =
its=20
way into the core of middlekit.
kapil