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
