Re: A DBA perspective.

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

See my comments inline:

David RR Webber wrote:

> Farrukh - I have a real problem when you make statements
> like this all!!!
>
> Well no surprises there ; -)

I made no personal statement about anyones approach nor used any derogatory
adjectives. I made technical statements on my technical beliefs

>
>
> <cola discussion snipped>
>
> 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?

ODMG 3.0 and therefor OQL is a standard. I did not say it is dominant. I will
quote myslef from my last proposal:

3. It is based on a dominant existing standard (SQL) and a not so dominant yet
existing standard (OQL)

SQL is a dominant standard. Anyone disagree? The constarined OQL approach is
nothing more than SQL subset with minor extesnions borrowed from OQL to support
method calls. I could just as well have used SQL3 or SQL99.

>
>
> 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?!

The issue is not the registry ineterface. The issue is a query syntax. Query
syantx is a very big wheel to re-invent (I believe I heard that wonderful cliche
from Duanne from your company in an earlier version of the Technical
Architecture document).

Inventing a registry interface is a necessity. Inventing a query syntax is a
very big deal and a very tough job to do. I do not have the intellectual cycles
to do 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.

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard