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, <tgallag...@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:matt...@matthewadams.me skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:matthewadam...@gmail.com msn:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
