Re: Unknown SQL

>"Bob" == Bob Badour <bbadour_at_golden.net> wrote:
>
>>> With the evolution of object databases things will change.
>
>Bob> Either you are extremely naive or you are blind to basic facts.
>
>Hey, calm down ...

I am calm. The statement is a true statement. Given the quality of Carl's responses, I am inclined to believe the latter.

>>> Ideally object databases do not need specialized implementations.
>
>Bob> Object languages expose physical implementation details to
 programmers.
>
>Not the ones I have seen; most have some more abstract pointer model in
 which
>the pointers are certainly not bare addresses, and are more akin to
>primary/foreign keys.

So, you are saying that all object languages use the same abstract pointer model and can share OID's and VTables? All support exactly the same set of redundant declarations (Array, Set, Bag, Collection) with exactly the same operators and performance characteristics? The common interface to the base object class is the same across all languages? All object languages support the same forms of inheritance? All object languages support polymorphism in exactly the same manner? All object languages have identical rules for which parameters pass by reference and which pass by value?

Which object languages have you used that leads you to the conclusion that they do not expose physical implementation details to programmers?

When it comes to OODBMS vendors supporting exactly the same programming language, they expose additional physical implementation details over and above those inherent in the language:

Some handle pointer swizzling and caching differently so that they have different rules for when the same OID will have the same physical pointer in memory. Differences in the concurrency model when they force the user to navigate procedurally through the database cause problems. They use different method names and interfaces for database access. They use different keywords for declaring persistence.

>Bob> So, every OO database is specific to a single programming language.
>
>Many OODBMS's nowadays do two or more from {Java, C++, SmallTalk}. And they
>should, and it even shouldn't be all that tricky to implement.

The point is that different languages have different needs. Most of Carl's statements only have validity in the context of a single language even when the OODBMS under discussion supports multiple languages.

In C++, I can pass an object by value to a function or operator just by declaring it so in the function's or operator's interface. I can control what it means to pass an object by value in the object's copy constructor definition. This is not possible in Java. Any OODBMS that supports both will have to take this into consideration.

>>> If object databases do not introduce unneeded own constructs, switching
>>> between vendors becomes very easy: You simply need no maintenance work
 at
>>> all. Load all objects out of one database and store it to the other.
>
>[ I agree with this, but I don't see it happining any time soon,
> unfortunately ]
>
>Bob> Provided you deal with a single programming language as implied by
 your
>Bob> 'respective programming language' statement above, and provided all OO
>Bob> databases for that language use the same OID format internally.
>
>I don't think some form of standardized portable OID is a priori
 impossible;
>URI's, IORs or Xpointer/XLink already seem to point that way.

The point is: When you identify data by uniquely identifying attribute values, you do not have to do anything to standardize. It is a priori unnecessary.

>Bob> You don't seem to get the fact that the value 10 remains constant no
>Bob> matter how one represents it.
>
>But that's an entirely different matter.

Actually, it goes to the very heart of the matter. It is the essence of the difference between OO databases and relational databases.

>SmallTalk is about the only language
>that chooses to make 10 a (singleton) object in its own right. And although
 I
>find this going a bit too far, there is logic behind it. Is "Wednesday May
 30
>14:23:03 BST 2001" an object? Well, yes, why not. It's an object with value
>semantics. Is "5.08 cm" an object? Is it a singleton? Is equal to, or
>equivalent with or identical with the "2 inch" object ?

It's not my fault if SmallTalk is fuzzy on the difference between a value and a variable.

>Bob> Philip gets it.
>
>If you mean me, I'm, not sure I 'get it'.

If you are the Philip who (on or about May 12) understood why identifying data by attribute values is more portable than identifying data by implementation dependent pointers, you do get it.

>>> Of course there are areas where standardization work will be necessary:
>>> 1.) Persistency callback functions
>>> 2.) Queries
>>> 3.) Locking and isolation level behaviour
>
>[ incidentally, much groundwork for this appears to have been done by the
>CORBA folks ]
>
>Bob> The rest of your message was too irrelevant for comment.
>
>[ These sorts of remarks detract from the real content ... please leave
 them
> out, you might risk being deemed irrelevant in turn ]

Why should I care? It's your loss not mine. Received on Sun Jul 22 2001 - 01:27:24 CEST