db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tgallag...@mmm.com
Subject Re: New Feature Idea
Date Thu, 03 Nov 2011 23:38:58 GMT

Thanks for the link.  I like that query functionality.  That will cover 
everything that would ever be required. 

However, I would also propose to also include the following which would be 
a really easy mechanism query data.  I'll show it as an example using the 
example on the page you listed and continuing with the Product object:

        public class Product
            long id;
            String name;
            double value;

Suppose you wanted all the products that start with "Wal", then the code 
would be something like this:

        Product product = new Product();

        List<Product> products = 
JDORecord_Utils.loadByExample(this.persistenceManager, Product.class, 
product, "name");

In the example above, the loadByExample parameters are:

        persistence Manager
        candidate class
        example object
        sorting field name

This results in a JDO query of:

        SELECT FROM mydomain.Product 
                    WHERE this.name.startsWith("Wal") 
                    ORDER BY this.name ASCENDING

In the case where the example object is null, the JDO query becomes:

        SELECT FROM mydomain.Product 
                    ORDER BY this.name ASCENDING

Let's say you wanted to do a subquery to find all Inventory objects 
containing a Product of a particular name.

        Product product = new Product();

        List<Inventory> inventory = 
Product.class, product, "id", Invetory.class, null);

In the example above, the executeSubqueryByExample parameters are:

        persistence Manager
        sub query candidate class
        sub query example object
        connecting field name
        candidate class
        example object

I understand that it is not a robust as the TypeSafe queries, and I will 
definitely make use of TypeSafe queries as needed.  However, the above is 
very useful for most of what I've seen over the years. My experience is 
building business layers that connect to datastores and building them in 
such a way that the GUI builders never include any queries/SQL directly in 
their code, which allows changing the datastore type and architecture 
without effecting the GUIs.

The issue I have is that even though JDO actually keeps track of what 
values have changed within a bean, there is no easy way to determine that 
from the developer's perspective.  So, I have to create a mechanism within 
the beans myself (items that are not persisted) in order to make this all 
work. If there were at least a way to easily gain that "changed field" 
information from a JDO object that would be great.  And from that 
indicator I would be able to get the field name and type using reflection. 
 Getting the changed field indicators is what would make the QBE work.

If I'm mistaken in not being able to get a change indicator that reliably 
identifies a field in the bean, please let me know how that is done. From 
the documentation there does not appear to be a standard way of doing 

Tim Gallagher

Clinical & Economic Research
3M Health Information Systems
5000 Buttercup Drive
Castle Rock, CO 80109

Phone: (303) 814-3867

Matthew Adams <matthew@matthewadams.me>
11/03/2011 04:36 PM
Re: New Feature Idea

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:


Check that out and see if it meets your needs.


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 
> 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 
> 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, 
> the required SQL and execute it.  This has been useful for about 95% of 
> 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 
> create generic QBE methods for using subqueries,  something I could not 
> before.
> Granted, QBE, does have its limits in that creating a this-or-that kind 
> query is difficult.  My current QBE is limited to "these values" types 
> 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 
> 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 
> this work.
> Thanks,
> Tim Gallagher
> Clinical & Economic Research
> 3M Health Information Systems
> 5000 Buttercup Drive
> Castle Rock, CO 80109
> Phone: (303) 814-3867


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message