Collection Object (there was a picture...)

[Philip Mötteli]

Am 01.08.2006 um 11:11 schrieb Philip Mötteli:
> Am 31.07.2006 um 21:35 schrieb Ruslan Zasukhin:
>> On 7/31/06 9:27 PM, "Philip Mötteli"  
>> <philip.moetteli at econophone.ch> wrote:
>>
>>>> Hmm, it seems SQL do not have query type which can do similar  
>>>> thing ..
>>>> OF course we can have low level API methods...
>>>> But SQL also is in interest
>>>>
>>>> It needs to think about this deeply. You have touch very
>>>> interesting issue.
>>>>     mix of Arrays, Links, Ptrs, ...
>>>>
>>>
>>> Definitely. Do others already have solved this problem?
>>>
>>
>> I have not see nothing similar to be automated.
>>
>
> So the arrays of Postgres you mentioned don't let do a search  
> through them?
>
>
>> I have realize that this is VERY strange query:
>>
>>     SELECT f3
>>     FROM NSSet
>>     WHERE RecID=1 AND f3.*.name='Ruslan'
>>
>> Why?
>>
>> Because here you make very weak assumption that all 3 tables T1 -  
>> T3 have
>> field "name".
>>
>
> That's almost true.
> Almost, because Yes, I make that assumption. So why does Apple  
> offer such a method to search for a value of an attribute? Because  
> it is no problem, if there's no such IVar/accessor method. Apple  
> first checks, if the attribute is there and only then accesses it.  
> This strategy is called Key Value Coding (KVC: <http:// 
> developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/ 
> Concepts/BasicPrinciples.html>).
>
>
>> In general case as I see it, tables Ti will have totally different
>> structures. Right?
>>
>
> Mostly, yes.
>
>
>> So such kind of query is useless
>>
>
> The objects might be different, so be in different tables, but  
> still have the same accessor method in three cases:
>
> 1. By chance.
> 2. Because they adhere to the same protocol/Interface (@protocol)
> 3. Because they are related by inheritance.
>
>
>> I think we need together spend time to write really complete  
>> specification
>> of tasks you want to solve in your layer. Having this list of  
>> tasks we can
>> think how this can be solved
>>
>>

I have another proposition how we could approach the problem (instead  
of looking how Postgres possibly does it): Lets assume the following  
M:M intermediate table:

MMIntermediate {collectionRecord as ObjectsPtr, nextRecord as RecID,  
memberRecord as ObjectsPtr}
-------------- next part --------------


(For the moment just ignore the 'nextRecord', which is there only to  
create an ordered collection).
So this MMIntermediate table would play the M:M table, joining the  
collection table (e. g. NSSet) to the destination table of the member  
object (here displayed by taking the root of all Foundation objects:  
NSObject). This would replace the array kind of field, proposed by  
Postgres and Ruslan.
How would searching work in this case? I mean, here too, I can search  
for a field of the member record, that possibly doesn't exist?


Re
Phil