[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Falko, what do you think of this?
On Mon, 18 Jun 2001, yduchesne wrote:
> Hi Falko,
>
> I have to know what you think of the following:
>
> A) We work with Gemstone in my shop; I was in charge of building a
> persistence framework on top of Gemstone, after we had tried to use de
> software as a plain-vanilla Java object cache (you take your object, you
> store it, period). The problem is we had many unexperienced developpers
> that did everything and anything with Gemstone, persisting this, persisting
> that. Chaos quickly arose from this... So I built a framework where
> developpers have to extend a given class, and use given collections. More
> precisely, we use tree-like objects - that have their own attributes, but
> that can also have collections of other objects. So we end-up with a
> tree-like object schema indeed, something really looking and feeling like
> XML, or, rather, typed XML per say, because we use objects with proper
> methods, not getAttribute(...) that returns a String.
>
> Next thing I did was building a query language on top of the framework,
> that uses reflection to resolve the attribute names in the query string to
> the corresponding methods; here are example queries taken from the doc:
>
> ([departments[]/employees[]/])
> Returns the list of all employees in all deparments
>
> ([departments[name=$1]/employees[]/])
> where $1=customer care
> Returns the list of all employees in the customer care department
>
> ([departments[]/employees[age<$1 and age>$2]/])
> where $1=25 and $2=45
> Returns the list of all employees below age 25 and above age 45
>
> ([payhistory[]/]) where key.emplKey in
> key([departments[name=$1]/employees[name=$1]/])
> where $1=customer care and $2=Joe Johnson
> Returns the list of all employees whose employee key corresponds to the
> employee(s) named Joe Johnson in the customer care department.
>
> ([departments[]/employees[age>$1 and [name!=$2 or name!=$3]]/])
> where $1=25 $2=Joe Johnson and $3=Bob Bobson
> Although this query does not make sense, it returns the list of emloyees
> whose age is greater than 25 AND whose name is not Joe Johson or Bob
> Bobson, in all departments not that we have anything against these guys.
> This is just to show how nested criterium work: the query engine performs
> an AND (instersection) between two sets: the one for the age AND the one
> with the nested criterium.
>
> ([departments[]/employees[type.name=$1]/])
> where $1=secretary
> Returns the list of all secretaries in all departments
>
> This proved really useful, let me tell you. In really cut our development
> time and made our job fun. PLEASE DO NOT FLAME ME, I've read about your
> opinion on a query language for Ozone... I think, with all due respect,
> that this would be a great addition to Ozone (ok, now you'll say: why don't
> YOU do it then???). I know, I know, but I am already on the doc project,
> still assimilating what Ozone is all about... I do not dare pretend I know
> Ozone enough to do it, period. I'm a newbie.
As I said earlier, I'm not against a descriptive query system for ozone or in
general. In fact I tried several times to push in this direction and find some
help and support to actually develop something. I just don't like those string
oriented query languages that produce the well known impedance mismatch between
application logic and database logic. But that's not the point.
Actually, I do have something in my backpack in this regard (some really cool
query by example stuff for a customer project ;) but currently I cannot work on
ozone features that I don't need in my own projects, sorry. I spend more than
one year doing nothing than coding ozone...
Of course, I would like to contribute ideas and even code but someone else has
to take the lead of such an effort.
As long as nobody is willing to actually donate some time it makes no sense
for me to do because then this feature is not really needed. If others jump
in and actually start working on it, then I will be more than happy to help (as
far as I can) because then the momentum comes out of real needs.
>
> B) How about notification built on top of JMS?
Another great idea! ;) Really.
>
> I mean, if a DB object is added/deleted/updated, it would be nice to be
> able to notify external listeners of theses changes - for synchronization
> purposes, replication, etc. Do you think a) this is a nice concept; b)
> using JMS for it would be appropriate; c) this is what Ozone is about?
a) sure
b) not sure but I think so ;)
c) ?
>
> Anyway, sorry to disturb you. Hopefully you're not irritated...
New/good ideas/questions are never disturbing. You know that. Thanks for
this post (and for your help with the doc project of course :)
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com