Collection Object

[Philip Mötteli]

Am 03.08.2006 um 09:20 schrieb Ruslan Zasukhin:

> On 8/2/06 8:19 PM, "Philip Mötteli" <philip.moetteli at econophone.ch>  
> wrote:

> Well, after this discussion may be lets begin from start?  :-)
>
>     Can you give e.g. some simple more specific example?
>     With NSSet, 2 tables T1 and T2 to be some objects..

What can I tell more?
Three tables NSSet, T1 and T2. NSSet has an M:M connection to T1 and  
another to T2. Instead of making this M:M connection, as a separate  
table, we have an attribute in NSSet, which is an array of OIDs.
Searching should be
1. by looking at the content of this array itself and
2. by dereferencing the OIDs and looking at their content.

E. g:

NSSet {Rec_ID recID; unsigned int n; Array of OID members;}	tableID = 1
T1 {Rec_ID recID; char *name;}	tableID = 2
T1 {Rec_ID recID; char *name;}	tableID = 3

(1)	SELECT	OID
	FROM	NSSet
	WHERE	members[*] == anOID

(2)	SELECT	OID
	FROM	NSSet
	WHERE	members[*].name == 'aName'

"SELECT OID" always means a subset of the content of the members array.

This array type of field should be able

1. ordered
2. allow multiple insertions of the same member (OID, or other type)
3. to address members randomly (not only serially)


> Let me again give point why I think inheritance the most correct way.
> it should be NOT only static storage of data.

Well, I actually prefer having nothing dynamic on the DBMS side.  
Dynamic things should be handled on the dynamic side. It's a question  
of dynamic redundancy and also compatibility.
I prefer having a small server program with DO, wrapping the DBMS,  
than putting anything dynamic into the DBMS.


> Valentina engine internally create for each table C++ instances of  
> Vtable.
> When they will have internal mechanism of inheritance, they also  
> should be
> able do some kinds of CAST and ala-virtual calls of methods.

The only useful thing, table-wise inheritance could bring me, would  
be the reduced redundancy of IVars/fields combinations. I mean, every  
subclass actually copies its super-classes IVars in its table  
representation.
But because I use the NSCoding protocol in order to serialize my  
objects, I almost can't distinguish, if an IVar comes from a  
superclass or not.


> Just up to know I always have think in C++ terms...
>
> You have show that exists more flexible way send messages and wait  
> who will
> answer...

We would also have aspect oriented message dispatching. But again, I  
don't think this would change a lot here for our collection problem.


Re
Phil