[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: OOQuery Language



On Tue, 19 Sep 2000, Mariusz Nowostawski wrote:
> Hi Falko, Don,  others ;o)
> 
> [...] 
> > Wouldn't it be easier to to all this in just one environment: XML? I mean,
> > why not transfering the data content into XML and using XPath (or another XML
> > query lang when available) to define the content of the report?
> 
> In fact this is exactly what we have considered some time ago. However,
> usually you have OO data modelled as UML diagrams, and the transition
> between pure OO (UMLish) view and XPath is somehow awkward. It is more
> natural (for the higher level) to represent data models as UML and ask
> queries in something like OQL, which can then, transparently to the user,
> be converted to XPath expressions, or any other 'native' format query 
> in which the data is physically stored.  If your top level model is
> expressed in XML Schema, then XPath is fine as a query language. However,
> to us, it seems to be nicer to have more abstract model of OO data, which
> internally can be stored in OO database, SQL-based database, Shapefiles,
> XML-based storage, etc. For this "more abstract" model we use UML, and XMI
> representation (serialization) of the UML for computations/resoning 
> (sort of data schema).

Ok, if there is to many business logic that has to deal with the data then of
course a real object model is much more efficient and much easier to handle.
But from Don's mail it seemed to me that his main focus is to _publish_
(making reports) the data. For this purpose I still think that an uniform XML
representation of the data has many advantages.

> 
> [...]
> > > Although I can understand the desire for a more OO query, my brief survey of 
> > > the genesis of OQL and other attempts at OO query languages convinced me the 
> > > definition of a robust new OO query language is not a trivial task. Although 
> > > S.O.D.A. and other alternatives may look interesting, AFAIK they don't have 
> > > a complete, rigorous definition to base an implementation upon. 
> > > This is why 
> > > I chose not to participate in  the earlier request related to implementing 
> > > S.O.D.A. OQL may not be elegant, truly OO, or computationally complete but 
> > > it's servicable.
> > Well, SODA is a totally new approach and it is work in progress. I agree.
> > 
> > Anyway, for me the most important questions is not what is the best OO query
> > lang (if such thing exists, anyway ;) but: how to evolve ozone so that it meets
> > the users needs. And it seems that people want descriptive query langs today ;)
> > 
> > All possible query lang solutions are based on the same principles, so I assume
> > that a generic kernel can be the back-end for all front-ends. Don, I understand
> > that the development of such a kernel is out of your scope. But what we need
> > now is not a ready-to-go software but a list of requirements that such a
> > kernel has to fulfill. Such a specification would be of real benefit for the
> > ozone development and for your development because it would clearly separate
> > ozone specific from independent code. If I got this right, Mariusz has
> > proposed such an architecture in his last mail. IMO his "driver" API is
> > exactly the API of "my" the query-kernel. What do you think?
> 
> 
> Yep, I finally got it ;o)  I have been following the discussion for some
> time now not fully understanding it, but it seems we were talking about
> the same things using different language. I fully agree with Falko here,
> and indeed his "query-kernel" is exactly what I was refering to as
> "modular interpreter" with the "multiple drivers" API. 
Yep.

> `I can describe what we have got so far. It is really rudimentary
> model, and we have simplified a lot of things, because we do not
> need currently full OO power.
> In our system we decided to model data as typed objects stored in typed
> collections, and all collection managers have to register the type and
> location of the respective collection with the resources broker. At that
> stage we know which collections can be served by which collection managers
> objects.  So if you call collection manager a driver, which speaks given
> API, and if you keep track (registry) of all drivers, and if you allow
> single driver to serve more than single collection, you have a
> picture.
> 
>      -----
>     | OQL |
>      -----
>        |                                         "top-level model"
>        V
>  -----------------       -----------------
> | Query Processor |<--->| Resource Broker |
>  -----------------       -----------------
>   |             | \
>   |             |   ---------                   "uniform OO model"
>   V             V             \
>  ----------    ----------    ----------
> | Driver a |  | Driver b |  | Driver c |
>  ----------    ----------    ----------
> 
>  SQL store     Shapedata      XML data            "native" level
> 
> 
> We do not support methods matching yet, and we do not support joins on the
> driver level yet. On the driver level we have just two methods: 
> 1. Collection getData(Object o);
> Returns a collection of Objects, such as for all non-null fields of the
> object o returned objects have the same values. This is equivalent of 
> select o 
>   from o in Collection 
>   where o.attr1 = value1 and o.attr2 = value2 and etc
> 
> 2.     Object getUniqueData(Object o);
> The same as above, but forces single result object.
> 
> Thus, "or" operator on the where clause is done by the query processing
> module by multiple calls to the "drivers", and joins are done by
> translating results from one subquery into a where clause of another
> subquery.  Path expressions are supported on the fields level by nested
> objects inside attributes, so if a field type is not String/Number,
> recursive matching is used, but we do not support nested iterators (nested
> queries in general are split by the query processor).  
> 
> On the top level we support CORBA-based object traversal (by value),
> and we think of supporting XML and possibly Java Remote objects (or by
> value). On the backend as I said, we have SQL based sources and Arc/Info
> sources, and in fact with current data and queries we mostly use
> getUniqueData call.  On the uniform OO model we have used Java objects and
> reflection, but it was terribly slow, so we decided to not support
> methods (like 'where o.method() = value') and we moved to use Hashtables
> instead, and we speeded up by a factor of 1000 most of the queries. 
> Joins are not efficient, and more thinking is needed for it.  What we
> think, is actually going a little away of the OQL with its iterators
> model, to a streaming mechanism, something like:
> 
> header (single discrete unit)
> select o where o.attr1 = $1 or o.attr2 = $2
> 
> body (stream)
> value1_1 value2_1
> value1_2 value2_2
>  ...       ...
> 
> 
> So we can make joins much more efficiently, and we could do partial
> evaluation as one of the sources progresses. There is a person who works
> on algebraic notation for it and some comprehension calculus, I am not
> that much into it ;o) but  we will report on that as soon as it is more
> clear.
> 
> I am not sure as for the API, beacuse in our model we have a seperate API
> on the Query Processor level, (which supports in principle all OO
> things) and a simplified version for "drivers" to translate a subset of
> OO query into native queries. The drivers are also responsible to
> preformat result into some sort of OO models (we use seperate
> schemas/mappings for SQL and other sources how to map rows into objects,
> etc).  
> As for Ozone maybe we should have something more like:
> 
> 
>      -----                  -------
>     | OQL |                | XPath |
>      -----                  -------
>        |                       |                "top-level model"
>        V                       V
>  -----------------       -----------------
> | Query Processor |     | Other Processor |
>  -----------------       -----------------
>        |                 /
>        |                /                        "uniform OO model"
>   ----------------------
>  | Uniform Query Kernel |
>   ----------------------
>     |           | \
>     |           |   ---------                   "internal OO model"
>     V           V             \
>  ----------    ----------    ----------
> | Driver a |  | Driver b |  | Driver c |
>  ----------    ----------    ----------
> 
>  SQL store     Shapedata      XML data            "native" level
> 
> 
> What do you think?  Should Ozone OO model be used as a "uniform OO
> model" or maybe it should be treated as a particular "native" level only,
> and something else should be the uniform model (another common API on the
> processor level).  To me, pure Java based model should be used inside the
> Query Kernel, however, I am not sure how to solve problem with objects
> identity in such model.  Also, in our case we need to be able to make
> joins across heterogenous sources, I am not sure it is generally a case,
> and maybe if there is only single driver at a time working with the query
> kernel the problem is much simpler.  

Ahhhh, great! Sounds like we found some guys who are experienced with OO query
langs :)

Question 1: should ozone object model be the "uniform OO model"?
In fact, the ozone model does add just persistence (not important for
query lang) and identity (via object ID) to the underlying Java object model.
So, I'm not sure and we have to check this again but ozone OO model seems to be
suited to serve as the "uniform OO model".

Problem 2: The APIs of the different levels.
Honestly, I don't have any ideas here. Do you have some code that we may
discuss about?

Problem 3: Level of abstraction of the different levels.
See Problem 2 ;) I don't have experiences here and I'm glad you are already
working on such a query-kernel-driver-thing ;) I like your very small driver
API.

Mariusz, it seems that you are working on a very interesting project. Is it
open source? Or is there a chance to integrate some of your technologies into
ozone?



-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com