Hi Tim,
We are in the process of standardizing similar functionality, called "type
safe query", which is currently functional, albeit proprietary, in the JDO
RI, DataNucleus:
http://www.datanucleus.org/products/accessplatform/jdo/jdoql_typesafe.html
Check that out and see if it meets your needs.
-matthew
On Thu, Nov 3, 2011 at 5:21 PM, <tgallagher@mmm.com> wrote:
> Hi,
>
> I've been working the JDO for about 6 months now. Prior to that I was
> accessing an RMDBs using a tool I created that built JavaBeans to
> represent the DB tables and to manage those tables. I would then build the
> business logic on top of that. Using JDO will allow me to expand the
> datastores that I can interact with. However, moving to JDO means that I
> have to again build a feature I use for about 95% of my DB interaction -
> Query-By-Example (QBE)
>
> With my previous methods, the JavaBeans kept track of items within the
> beans that have changed. Whenever I wanted to query a table, I would
> create a JavaBean related to the table, set a few values within the bean
> and then user a general query mechanism that would look a the bean, build
> the required SQL and execute it. This has been useful for about 95% of my
> DB interaction and greatly reduced the amount of SQL written into the
> business layer.
>
> Moving to JDO, I no longer have that. However, I have built that same
> mechanism into my JDO related JavaBeans. Using JDO I was further able to
> create generic QBE methods for using subqueries, something I could not do
> before.
>
> Granted, QBE, does have its limits in that creating a this-or-that kind of
> query is difficult. My current QBE is limited to "these values" types of
> queries (eg. querying a table based on the table's record id) or, for
> String values, using "Like" functionality. But my experience with
> database interaction for the last decade is that this covers the vast
> majority of the queries.
>
> I would like to discuss this further with you to determine who this kind
> of functionality can be included in the spec so that I don't have to keep
> re-inventing it with every new datastore access technology. I can show
> you examples of what we do here at 3M and go over what is required to make
> this work.
>
> Thanks,
> Tim Gallagher
>
> Clinical & Economic Research
> 3M Health Information Systems
> 5000 Buttercup Drive
> Castle Rock, CO 80109
>
> Phone: (303) 814-3867
>
--
@matthewadams12
mailto:matthew@matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@gmail.com
msn:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
|