You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by tg...@mmm.com on 2011/11/03 23:21:49 UTC
New Feature Idea
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
Re: New Feature Idea
Posted by tg...@mmm.com.
Sorry for the delay on the "new feature". I was experimenting with using
a TransientStateManager, and the effects it would have on an object that
is made persistent.
I would like to send the JDO group some source code that is generic enough
to include as part of the JDO release.
Since I did much of the original work for 3M, I'm wondering what is your
policy about sharing source code? Can their be a "Originally developed by
3M" indicator in the source code that would remain during distribution?
I'm still checking with 3M about its open source policy, so I hope I can
share this, but we will see.
Thanks,
Tim Gallagher
Clinical & Economic Research
3M Health Information Systems
5000 Buttercup Drive
Castle Rock, CO 80109
Phone: (303) 814-3867
From:
tgallagher@mmm.com
To:
jdo-dev@db.apache.org
Date:
11/03/2011 05:39 PM
Subject:
Re: New Feature Idea
Matthew,
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:
@PersistenceCapable
public class Product
{
@PrimaryKey
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();
product.setName("Wal%");
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();
product.setName("Wal%");
List<Inventory> inventory =
JdoRecord_Utils.executeSubqueryByExample(this.persistenceManager,
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
this.
Tim Gallagher
Clinical & Economic Research
3M Health Information Systems
5000 Buttercup Drive
Castle Rock, CO 80109
Phone: (303) 814-3867
From:
Matthew Adams <ma...@matthewadams.me>
To:
jdo-dev@db.apache.org
Cc:
tgallagher@mmm.com
Date:
11/03/2011 04:36 PM
Subject:
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:
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, <tg...@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
Re: New Feature Idea
Posted by Andy Jefferson <an...@datanucleus.org>.
Hi,
> However, I would also propose to also include the following which would be
> a really easy mechanism query data.
I'd agree that QBE would add something to JDO queries over what is already
there, or planned. The Typesafe query seems to be drifting into JDO 3.2 IIRC,
so plenty of time for proposals of how this could work (and for contributions
to DataNucleus providing an implementation).
> Suppose you wanted all the products that start with "Wal", then the code
> would be something like this:
> Product product = new Product();
> product.setName("Wal%");
I wouldn't necessarily use values of String fields to imply startsWith though.
A field could have a value with "%" in it for other reasons, so its value
should only be used for equality, or maybe <, >, <=, >= for numeric fields.
To have an object of a persistable type with fields set, and be able to say
Query q = pm.newQueryByExample(Person.class, myPerson, "lastName");
to get all Person objects with the same surname as the example Person.
Query q = pm.newQueryByExample(Person.class, myPerson, "age", OP_LT);
to get all Person objects with age less than the age of the example Person.
would be great.
Obviously all these are really doing behind the scenes is create a standard
JDOQL Query object with a filter and certain parameter values. In particular
for these examples
SELECT FROM mydomain.Person WHERE lastName == :param
SELECT FROM mydomain.Person WHERE age < :param
i.e nothing that isn't workaroundable right now, just for convenience its
sometimes nice to express as you say.
> 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.
JDO keeps track of changes *when the object is connected to a StateManager*,
and only then. If an object is not introduced to the JDO persistence mechanism
(not persisted) then it has no StateManager, so the mechanism doesn't benefit
you.
--
Andy
DataNucleus (http://www.datanucleus.org)
Re: New Feature Idea
Posted by tg...@mmm.com.
Matthew,
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:
@PersistenceCapable
public class Product
{
@PrimaryKey
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();
product.setName("Wal%");
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();
product.setName("Wal%");
List<Inventory> inventory =
JdoRecord_Utils.executeSubqueryByExample(this.persistenceManager,
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
this.
Tim Gallagher
Clinical & Economic Research
3M Health Information Systems
5000 Buttercup Drive
Castle Rock, CO 80109
Phone: (303) 814-3867
From:
Matthew Adams <ma...@matthewadams.me>
To:
jdo-dev@db.apache.org
Cc:
tgallagher@mmm.com
Date:
11/03/2011 04:36 PM
Subject:
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:
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, <tg...@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
Re: New Feature Idea
Posted by Matthew Adams <ma...@matthewadams.me>.
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, <tg...@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