|Subject||Re: [Firebird-Architect] RFC: Proposal for the implementation|
> > So - we need more lightweight and simple TempCacheManager. IdeallyProbably i was misunderstood. I didn't speak that TempCacheManager is all
> >it can be inherited from abstract base CacheManager class
> This is just wrong. Think about it some more. Hint: the major changes
> aren't to the cache manager. Even better, do some research.
of we need. I didn't say that cache manager is major changes. I just say that
current CCH don't satisfy the needs of temporary page management. So we need
a new _additional_ lightweight cache manager exclusively for temporary pages.
> > Option a) needs no data page management, it simple create new file fortemp
> >table data and more files for its indeces. All other options require to trackIdea is to isolate records from different table instance on defferent pages.
> >pages list and to provide above allocation policy.
> There already is a space management policy implemented. You don't have
> to invent another. (This is called "leveraging code").
It will allow instant cleaning up from that table instance after use.
Current allocation policy allow to allocate on the same page data rows from
temp table instances of attachment 1 and attachment 2 (or tx1 and tx2 in case
of ON COMMIT DELETE)
> Let me give you another hint: Use objects. Think about internalI'll try ;-)
> layering. When you find the right answer, it will be obvious.
PS Sorry, i'm wrongly press 'Reply-to-sender' at first time