[Fwd: RIM 0.54 and RS 0.83 distribution]

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

--
Regards,
Farrukh

---

• From: Farrukh Najmi <najmi@east.sun.com>
• To: Michael Rowley <mrowley@exceloncorp.com>
• Date: Thu, 18 Jan 2001 10:28:32 -0500

Mike,

Thanks for your comments.

See my comments inline. I would be grateful for your help in further
simplifying and constraining the BNF grammar for the query.

Michael Rowley wrote:

> Farrukh,
>
> I was reading your query BNF and had some questions.
>
> Are you sure you want the "IN" clause, with arbitrary nesting of
> subqueries?  I think this would be especially hard to implement
> efficiently with anything other than a relational databse.

I think a simple scope reduction would be to allow only a single column
identifier instead of a nested select. This could be restricted to a
collection attribute in RIM.

>
>
> In general, it looks like your subset would allow queries that I think
> would be difficult to implement if you stored your data in XML, or any
> form other than in a relational database:

IMHO the subset SQL syntax is the most mappable to any backend store choice.
I believe  that if we pick a document centric syntax it would be even more
difficult to map to a relational store. Correct me if I am wrong but the
subset SQL syntax should be realtively easy to map to an Object store that
simply stores objects as defined by RIM (rather than as defined the document
DTDs mapped from RIM).

I agree that picking an XML syntax would be easier for an XML store. However
the solution would then be biased towards an XML store implementation. I
believe that the subset SQL syntax is the closet to an OO information model
(specially when compared to a document based information model). It seems to
me to be the least of all evils.

>
>
> For example, the following queries for all unique combinations of the
> values from the x and y columns of table 'a', and the z column of table
> 'b'.
>
> SELECT DISTINCT a.x, a.y, b.z FROM a, b

The above would not be legalaccording to the grammar below:

    SQLSelectCols = ( "ALL" | "DISTINCT" )* [ "ID" ]

which restricts SQLSelectCols to be a single ID which is required to map to
a RIM leaf class.

>
>
> Here is one that would do a 3-way join:
>
> SELECT FROM a, b, c WHERE
>    a.x = b.x and b.y = c.y and a.z = c.z
>
> Of course, nested subqueries could be used to create some hairy requests
> as well.

We could eliminate nested sub-queries as I said earlier.

>
>
> In one of your recent email's, you said that you implemented the query
> processor for this BNF in 4 hours, but mentioned that you hadn't bound
> it to your back end yet.  It seems like you have primarily just done
> parsing then, which is usually easy, so it doesn't surprise me that
> it would only take a few hours.

Yes that is what I did. Since this morning I am about 25% of the way to
binding to my backend.

>
>
> One of the main arguments made after the invention of SQL was that you
> can create a language which appears to be asking for very run-time
> expensive behavior (joins, cross-products, etc), but that with a
> sophisticated query optimizer, it should be possible to actually execute
> the query in a reasonable amount of time.  I would hate to require that
> people either use a relational database, or implement their own query
> optimizer.  It is hard to write a query optimizer.  That is one of the
> main reasons that JDO chose a filtering-based query feature, which does
> not open the possibility of arbitrary joins and cross-product creation.

I believe that by tightening up the spec further (e.g. eliminating nested
queries) we could minimize the implementation complexity. Note we have
alreaduy eliminated outer joins. Any ideas on how to constrain simple joins
further would be appreciated.

>
>
> Michael

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

---

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