Collection Object

[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 attribut? 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
>
> If you want I can setup for you account in our DokuWiki.

If that helps, of course.


> P.S. EOF - is layer over third party RDBMS. So inheritance they  
> have is far
> far  away from what we need in Valentina. I talk about inheritance  
> on db
> storage and db ENGINE (!!) level.

I know that, but still…


> Benefit if this -- you do not need work with all that internal  
> fields and
> manage them. This will do db engine. Like C++ language manage for  
> us virtual
> tables. We just use them

I don't doubt, that it is more efficient, but I don't see, how you  
solve the collection problem with it.


Re
Phil