Ian Bicking: the old part of his blog


Hi Ian:)

This really sound strange for me. Despite i used Modeling for over 2 years now, I'm wondering why you want to have the same thing in SQLObject.

Should SLQObject have the same API than Modeling, or MiddleKit ?

I really think SQLObject is good for what it tend to be: 'fetching raw in the DB','caching results' and 'saving them when needed'. Modeling is far more complex, with its validation scheme, nested editing context and so on ..

Beside i'm not a SQLObject developper, i don't really understand why you again try to _clone_ the EOF. If you really want this kind of stuff, why you don't help Modeling guy (Big) which (i really think) will be happy to count a new developper. (the team is quite small right now)

-- Random things: ---
-In the EOF there is some qualifier for fetching objects so ec.Person.get(1) really sound strange.
- The major reason why i like SQLobject it's because it do what it should. There is nothing magic about it. Simply caching by IDs. So now, if you try to write a application that use the a DB Api which do a lot of magic, like 'nested' Editing Context. This is far more complex, because you need to think about 'in which context i'm', 'is this object is my parent Ec ?' and so on .. this is why I now use SQLObject over Modeling. I need something simple, thread safe ..
- And anyway, if you really want to do something like this, take a look closer at the Modeling API. To insert a new object in DB, simply add it too the Editing Condext and ec.save() it. no new() magic ..

Bye Bye..
Comment on SQLObject API redesign
by Jkx