Re: A DBA perspective.

[David RR Webber <Gnosis_@compuserve.com>]

Farrukh - I have a real problem when you make statements 
like this all!!!

Well no surprises there ; -)

For once its seems like we are actually saying the same thing - 
but just the terminology is the issue - when I say 'stored procedure'
you are jumping to a specific implementation - where I am using
the term generically to mean a 'blackbox' business function of
the API.   When you talk about Objects I'm referring to reusable
components.  Ok - this is like drinking Coke instead of JCola - 
there are both still sodas!

What's this about OQL?!?  That's a specific query syntax 
however which way you want to slice it - and 
I thought we'd already agreed this dog will not hunt?  If its 
such a hugely available standard why is Oracle not supporting
it?

What's this about homebrewed syntax?  Hey - that argument
can be applied to ALL the syntax so far developed for 
registry - its just something someone made up - and the
only point is that it is using angle bracket markup called
XML.   Containers for content.   If we are not allowed to 
ever do this because it is some kind of mortal sin - why
is everyone else doing it?!

OK - let's see if we can agree on sodas.

See my notes below.

Thanks, DW.
==================================================
Message text written by Farrukh Najmi
>
 
I want to point out that stored procedures are an implementation detail. IN
contrast the methods defined in RIM 0.54 (
http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00086.html )

used by the OQL approach are elements of registry specifications. It should
be noted that the constrained OQL approach could be implemented to map the
speced relationship methods in RIM to stored procedures directly (as an
implementation choice). 

>>>>>>>>>>>  Ok - so why choose OQL at all?  
             If we stick to the highlevel we avoid
             any query syntax specifics at all.
             An implementor can then choose
             whatever they please - at the level
             of the API the backend query 
             syntax is not visible.
                           

In my own implementation I personally would stay
clear of stored procedures based on a very long history of having
implemented database engines as well as query processors. They are a
maintainenec nightmare and are not implemented in a standard way across DBMS
(one loses DB portability).

>>>>>>>>>>> Exactly - so we define 'blackbox' procedure behaviour.
            I'm not suggesting that you personally should 
            maintain every registry implementation on the 
            planet.  All we care about is consistent behaviour.
            If I invoke getRegistryObject against two 
            different registries - I should get the same result
            set - I care not what internal hoops they are 
            jumping thru.

I would instead choose to define methods on implementations of objects (e.g.
ManagedObjectImpl) defined by RIM to return a SQL query as a direct and
simple mapping of the relationship method. The OQL processor would call
these methods to resolve these methods calls to their equivalent SQL
queries. It would then apply any simple global optimization over the query
predicate and then simply pass the resulting SQL query to the relational
database.
>>>>>>>>>>> Overuse of the word simple.  You just told me 
            that writing code is a nightmare to 
            maintain - so why are you saying to write
            SQL and OQL now?  Let's define those 
            methods of the objects and we are done.
            We then state that implementors will
            choose to map these to their own
            query syntax as needed.  The 
            only common thread is that the
            content exchanged is passed 
            inside of XML containers.


The key difference in the 2 approaches being debated is that the constrained
OQL approach is based on standards (SQL, OQL) and is familiar to use for
most implementors, while the custom XML qyery syntax is a home brewed query
language syntax that does not have the strength of years of experience,
review and expert contribution that the former approach does.

>>>>>>>>>>> OQL familiar?  So more people know OQL than XML?
            XML does not have years of experience?  Farrukh
            what do you think I've been doing for the past 23+
            years?  Writing memos, making phone calls
            and playing solitaire?
                           
            We need ad hoc querying that average end
            users can handle.  Simple XML containered
            API approach will reach more people easily
            than requiring knowledge of a specific
            query syntax - I don't care which one you
            choose.

DW.