[ORM]: faulting

[Thorsten Hohage]

Hi Philip,

On 2007-10-11, at 14:21, Philip Mötteli wrote:

> You just implemented a different memory management for a persistent  
> collection object. So there's a need either to transparently  
> replace the original, non persistent collection object or you urge  
> the user of your library to do it manually, by instantiating a  
> special collection object, that uses a different memory management.
You talk here about a much lower "level" in the framework, then I  
did. I'm right that you know about EOF? So beside all aspects of  
memory management I've thought of the EOEditingContext objects. And  
you're able to cascade the context objects or bound the context on  
"other elements". When now talking about desktop apps using a context  
for e.g. each window, will only kept the faults as long as the window  
lives - this is just an example, beside the question if this is good  
or bad code style.

But of course when thinking about building such a framework on our  
own THEN we need to leave this abstraction level and deal with the  
things you mentioned and then yes, you're right, of course.

>  But if you just transparently take the non persistent collection  
> object, you end up with as many faults as you have elements in this  
> collection object.
What I tried to point out, that a non continuous running app (=read  
desktop app in this case) with a common business usage never will  
need ALL data. You only search customers you deal with during the  
day, create probably more invoices then you search, ... so you will  
never retrieve all data from the db or better/concrete you'll never  
need to create faults for ALL data in the db.

Working with faults, didn't mean you need to load ALL recID/UID/OID  
from a table initially, but I think you know this. Of course there  
may be some requirements to do a full load of i.e. property tables,  
but these are typically small tables.  And I repeat myself, if you  
need to load the full DB during working with your app, then maybe ORM  
is not a good choice.

And finally when thinking about 24/7/356 apps like app servers in a  
theoretical way, then you're absolutely right - there will be a point  
where you'll have as many faults as db rows.


> I don't know, how they call it in Ruby or RealBasic.
Talking in Obj-C, or concrete in NS..., WO..., EO... class name will  
give me a warm feeling of coming home ;-), so don't worry about RB  
names here.

> But if you serialize and then deserialize an NSArray object, you  
> will have an NSArray instance with as many faults in it as there  
> were originally elements.
> So to solve this, you do what I described here:
>
>>> But, objects, that collect other objects are collection objects.  
>>> OO is about reusing code. So a programmer shouldn't re-implement  
>>> collection objects. He should reuse the ones, that are already  
>>> there. Which means, that the persistence library can also replace  
>>> them or part of them, so that they use an optimized memory  
>>> management.

Theoretical you're right here again and pratical for some cases. But  
I would think about using several NSArray (or more abstraction level  
EOEditingContext) and one is tied to the current process (e.g.  
Window). So after you finish using it, you not deal with objects  
inside the NSArray and try to do object management, but you throw  
away the whole NSArray.

A lot of the "good ol' concepts" (especially EOF) are designed with  
an app server in mind, not a desktop app. So while throwing away a  
NSArray full of faults is theoretical complete nonsense and for an  
app server in practical way, too (because the app server should take  
load away from the db) - it's necessary to find solutions for the  
specific need of desktop apps, e.g. not consuming the full 2GB of  
memory.


regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany