You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by "Clute, Andrew" <An...@osn.state.oh.us> on 2004/03/31 04:39:44 UTC

Anybody found a good pattern for nested-attributes for queries?

I am in the process of developing an architecture that junior/inexperienced programmers will be using to build websites with, based around OJB. One of my design goals is to make as much as possible be compile-time checked to reduce the number of runtime errors that could be introduced (real productivity killers for newbies).

So, as part of this, I have added static String fields to all of my Data Objects that map to a field that is persisted with OJB, to remove explicit Strings being written in client code.

So, instead of doing something like this:

	criteria.add("firstName","Andrew");

we use:

	criteria.add(Person.FIRST_NAME,"Andrew");


This works fine for most of the cases, and makes it easy to use in Eclipse because AutoComplete is pretty much telling you exactly what is available to be queried from the database. I like it in theory. However, where it does fall apart in 'cleanliness' is when you want to do a search of nested objects.

So, instead of doing an explicit query like this, which is clean, but not compile-time checkable:

	criteria.add{"homeAddress.state.twoDigitCode", "OH");

I have to do something like this to keep my same pattern as above:

	criteria.add(Person.HOME_ADDRESS + "." + Address.STATE + "." + State.TWO_DIGIT_CODE,"OH");

It gets the job done, but it is tough to read, and error-prone.

In my ideal world, I would like to be able to do something like this:

	criteria.add(Person.HOME_ADDRESS.STATE.TWO_DIGIT_CODE,"OH");

where the objects are cascadable, and they appear in AutoComplete. Now, I could just as easily add Static Objects that represent the nested objects, as opposed to String that terminate the chain. This would allow me to be able to walk my path above easily, but the end result of that String will not be the fully-qualified path to that attribute. Instead it would be the value associated with the last member in the chain ("twoDigitCode" versus "homeAddress.state.twoDigitCode").

So, I am open to suggestions, and would love to hear what people are doing elsewhere. My current implementation works, and I can live with it, but there has got to be a better way!

Thanks

-Andrew





---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org