Re: A DBA perspective.

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

David,

Let me be very clear. The alternative you propose is still in teh concept stage.
We need specific examples of how it would address the sample queries that I have
identified in:

http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00098.html

Forget the OQL syntax. Just look at the plain english that preceded the OQL
examples and show the team how your approach would address those queries. Until
you do, the approach is not an alternative that has been proven to meet the
proposed requirements. If there is an issue with the requirements lets talk
about it.

If you need any help understanding the english language intent of the queries or
any aspect of RIM I will be glad top help in your effort to make your approach
into a viable alternative. You have my phone number in the signature below.

David RR Webber wrote:

> 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.

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