[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query kernel
hi falko,
i understand ur problems
but right now we r stuck.
the source code is just too big
since there is not much documentation
it would help if we know what portion of
code to deal with so that we could try and
understand that part properly
i know how an ODBMS works but
dont know how exactly Ozone does since
it doesn't fully support ODMG standard.
i got the idea of proxy objects and all that
but not anything yet about low level storage and stuff like that.
i know a decent amount of SQL and OQL.
what i think is the following
suppose we develop a query api for OQL
we get an idea of how the api should be.
so this can be extended to support say SODA
and finally we will have a language independent kernel
otherwise its difficult thinking of what api to expect
what do u say
bye
das
On Sun, 1 Apr 2001, Falko Braeutigam wrote:
> On Sun, 01 Apr 2001, Dasarathi wrote:
> > hi falko,
> > i need to chat with u online
> > for some 10 mins at least.this is very important
> > to us.
> > if u r using aol, yahoo or msn messenger
> > please tell what time u will be available
> > mailing causes lot of delay.
>
> das, we should really to try to keep this in the mail list (email instead of
> chat) in order to keep others up to date what's going on and the encourage them
> to jump in.
>
> Anyway, I'm not sure if I can give you more info via chat than via email. The
> query kernel is just an idea. I know, people would love to have something like
> that in ozone. Anyway, I don't have a clear vision how the design should look
> like or even what are the concrete goals of the query kernel. All that I know
> is how ozone works and how RDBMS work and the advantages/disadvantages of the
> two. I assume you know this too. As I mentioned earlier there are two options:
> 1) you come up with a clear vision and design of the query kernel yourself. I
> already gave you (nearly) all information that I'm able to give in this regard.
> So you can start immediatelly. 2) I will do the design. I'm currently about to
> finally check out EJB. This work is strongly related to the query kernel.
> However, this takes me at least 3-4 more weeks to work on.
>
> Finally, I don't use any messenger - just email ;) If you really think we
> _must_ chat, then you will have to advise me what to do ;)
>
>
> Falko
>
> >
> > reply asap
> > bye
> > das
> >
> >
> > On Fri, 30 Mar 2001, Falko Braeutigam wrote:
> >
> > > On Fri, 30 Mar 2001, Dasarathi wrote:
> > > > hi ,
> > > > now we have got some clear idea of what is to be done
> > > > i want an idea of how wizardstore works.
> > > > i have started looking at the code
> > > > do u have some documentation with u
> > > > after we understand how objects r stored
> > > > we can proceed with the algos.
> > >
> > > IMO the query kernel should be completly independent of the ozone kernel
> > > implementation - like the XML sub-system. It should be a layer on top of the
> > > 'native' ozone API. If we will find that this 'native' ozone API is currently
> > > not able to handle this, then we can and should consider to change this. But
> > > I'm pretty sure that the query kernel should not depend on the underlying
> > > backing store. The backing-store should be pluggable. If the query kernel
> > > relies on the backing store than we need one for each backing-store.
> > >
> > >
> > > Falko
> > >
> > >
> > > >
> > > > bye
> > > > das
> > > >
> > > >
> > > > On Fri, 30 Mar 2001, Falko Braeutigam wrote:
> > > >
> > > > > On Thu, 29 Mar 2001, s dasarathi wrote:
> > > > > > hi falko,
> > > > > > i had some doubts while thinking
> > > > > > about the kernel.
> > > > > > it has to have front ends for OQL, SODA etc etc
> > > > > > say for OQL, we need to have some interpreter that
> > > > > > converts the queries to some statements which will
> > > > > > be understood by the kernel.
> > > > >
> > > > > This would be one approach but not the best I guess. The query kernel should
> > > > > provide a Java API that is able to serve as the back-end for several front-end
> > > > > systems (even non-text-language systems).
> > > > >
> > > > > > and the kernel returns the result of the query
> > > > > > in a manner understood by the front end which then
> > > > > > outputs it to the user.
> > > > > Yes. Such a front-end system would have to interpret the "language" that it is
> > > > > designed to support (OQL, SOADA...) into query kernel API calls and vice versa.
> > > > > But it would _not_ have to deal with the implementation of the query algorithms
> > > > > itself. The kernel provides a rich API (and implementation) that hides the ozone
> > > > > specific (and probably tricky) implementation from the fron-ends.
> > > > >
> > > > > >
> > > > > > if all the above is fine then it is just
> > > > > > a matter of retrieving data from the DB.
> > > > > > what other functionalities do u think this kernel should have??
> > > > > see above
> > > > >
> > > > >
> > > > > Falko
> > > > > --
> > > > > ______________________________________________________________________
> > > > > Falko Braeutigam mailto:falko@smb-tec.com
> > > > > SMB GmbH http://www.smb-tec.com
> > > > >
> > > >
> > > > Your Fortune
> > > > If God had intended Men to Smoke, He would have put Chimneys in their Heads.
> > > --
> > > ______________________________________________________________________
> > > Falko Braeutigam mailto:falko@smb-tec.com
> > > SMB GmbH http://www.smb-tec.com
> > >
> > >
> --
> ______________________________________________________________________
> Falko Braeutigam mailto:falko@smb-tec.com
> SMB GmbH http://www.smb-tec.com
>
>