Re: [GENERAL] Retrieval of OO objects.

Chris Bitmead wrote:
>I guess the point is if you had an Eiffel collection of animals, two
>Invertebrates and two vertibrates, and did a save to disk. When you
>loaded the collection back in from disk you wouldn't expect to get back
>4 animals, whose status as vertibrates or invertibrates is no longer
>known.
>
>In a real object database, you could say "Get all the animals", and they
>would come back appropriately - some as vertibrates, some as
>invertibrates. Since they come back properly we can call methods on
>different types of animals and they will behave differently as
>appropriate.

That is so; however, if you use class `animal' only, you can see only the
features that are appropriate to animals as a whole. To see features of
more specialised classes, you have to use those classes.

To take a real-life example in PostgreSQL:

Table = person
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| id | char() not null | 10 |
| name | text not null | var |
| address | int4 | 4 |
| salutation | text default 'Dear Sir' | var |
| envelope | text | var |
| email | text | var |
| www | text | var |
+----------------------------------+----------------------------------+-------+

Table = organisation (inherits from person)
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
[inherited fields]
| contact | char() | 10 |
| structure | char() | 1 |
+----------------------------------+----------------------------------+-------+

Table = customer (inherits from organisation)
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
[inherited fields]
| acs_code | char() | 8 |
| acs_addr | int4 | 4 |
| class | char() default '' | 1 |
| type | char() | 2 |
| area | char() | 2 |
| country | char() default 'GB' | 2 |
| vat_class | char() | 1 |
| vat_number | char() | 12 |
| discount | float8 | 8 |
| commission | bool default 'f' | 1 |
| status | char() default '' | 1 |
| deliver_to | int4 | 4 |
| factor_code | text | var |
+----------------------------------+----------------------------------+-------+

Table = supplier (inherits from organisation)
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
[inherited fields]
| terms | char() | 2 |
| acs_code | char() | 5 |
+----------------------------------+----------------------------------+-------+

In this case, customer and supplier both have a field `acs_code', but the
lengths are different and the meaning is different (customer account code and
supplier account code). I could define a field `status' for supplier
which was a CHAR (like the one in customer) but meant something entirely
different: customer status - null = normal, s = suspended, p = prepay only;
supplier status - p = preferred, x = no longer used. I might also have
another inheritance tree of individual inheriting from person, where status
is - s = single, m = married, d = divorced.

It would be wrong to mix these columns into one, because their meanings are
different. If you were to `select status from person*' which column should
be shown?

You are right to say that all data should be retrievable, but wrong in
wanting to attach descendant features to an ancestor class.
In this example, if I want a list of contacts, I must `select contact from
organisation*', because person does not have a contact field. I lose
nothing thereby, because there is no information to be got from any other
sub-trees about contact. If any other descendant of person does define
contact, it does not have the same meaning as does contact in organisation
and it should not, therefore, be reported anyway.

--
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"But as many as received him, to them gave he power to
become the sons of God, even to them that believe on
his name." John 1:12