OID / ObjectsPtr

[Ruslan Zasukhin]

On 11/17/04 6:01 PM, "Erik Mueller-Harder"
<valentina-list at vermontsoftworks.com> wrote:

Hi Erik,

> I'm curious as to how development is going on the table-independent OID
> concept.  Does this look like something we might be able to try out in
> the next couple of weeks, or will it take longer?

> I ask, because I'm suddenly in a position where I think it could be
> extremely useful:  I have a kind of index table with records that
> should point to records on any of a dozen or so other tables.  Being
> able to store each target's OID rather than a tableID/recID combination
> might be very nice....

Look.

In C++ kernel I have create draft of another new field type

        ObjectsPtr      pointer to OID
             ^^^   

Differ from     
        ObjectPtr       pointer to RecID


But the more I did think on this the more problems I have see.
- no way for cascade deletion. You need walk on all tables of db to check
that OID.

So it looks to me, you can just use OID self, without any help from engine.
OID field work right now, yes?

So you can store its values in the some ULLong (8 bytes) field.
All rest is up to.


Of course in the future I will try to find some more ideas for ObjectsPtr.
For example, I think in real task developer will have structure

        ONE table can point 2-3-4-5 tables.
        but db have another 10-20 tables.
    
I.e. Exists sense info, ObjectsPtr field about this POSSIBLE Targets.
Then we need check only these 5 tables, but do not touch rest 10.
This is the only optimization I can invent for now.


-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------