db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Bengtson" <e...@jpox.org>
Subject RE: #key and #value in query filter?
Date Tue, 30 Oct 2007 21:39:16 GMT
IN can be replaced with the following, but I cannot think on anything else
to replace #value and #key. (maybe getKey(), getValue())

SELECT this.images#value
WHERE keys.contains(this.images#key)

keys = ['thumbnail', 'full', 'high-res']


SELECT this.images#value
WHERE {'thumbnail', 'full', 'high-res'}.contains(this.images#key)

-----Message d'origine-----
De : Matthew Adams [mailto:matthew@matthewadams.org] 
Envoyé : mardi 30 octobre 2007 21:58
À : Erik Bengtson
Cc : 'Apache JDO project'; 'JDO Expert Group'
Objet : Re: #key and #value in query filter?

Yeah, so what you're proposing is completely different...  Please  
start a different thread on that.

WRT this thread, which is a discussion on how to support something  
less verbose and complicated than what JDOQL currently requires to  
support this.  What I'm seeing in JDOQL right now with regard to  
querying through keys and values in Maps is not a simple as what I'm  
seeing in JPAQL.

Is there some way to make querying through Map keys and values simpler?


On Oct 30, 2007, at 1:37 PM, Erik Bengtson wrote:

> Interesting that you mention Maps on queries, because I have another
> proposal.
> The example says all:
> <example>
> Map result = (Map) pm.newQuery("SELECT new Map<name,this> FROM
> Person").execute();
> result.get("jordan") returns Person[name=jordan,firstName=michael]
> result.get("simpson") returns [ Person[name=simpson,firstName=bart],
> Person[name=simpson,firstName=homer] ]
> </example>
> That means, the query is actually not run when query.execute() is  
> invoked,
> but on each operation over the returned map.
> The map instance returned, is a 2 layers map:
> 1-entries fetch from database (datastore entries)
> 2-entries added via map.put or already loaded from db (local entries)
> Below I describe the contract for the Map instance returned:
> Map.size()
> When a transaction is active and query not closed: Delegates to JDO
> implementation, that ultimately performs a SELECT COUNT(*) in SQL  
> databases.
> The local entries are intersected with the SELECT COUNT(*) entries.  
> The
> intersection count will be the size() return value.
> Otherwise: Performs a size() over the local entries.
> Map.put()
> Put a new entry to the local map entries. Not persisted.
> Map.remove()
> Remove the entry from the local map entries. Not removed from  
> database.
> Map.get()
> When a transaction is active and query not closed: First checks  
> local cache,
> if found return, otherwise fetch entries from the datastore and add  
> to the
> local entries.
> Otherwise: Performs a get() over the local entries.
> When a PM or Query is closed, the map is disconnected and only the  
> local
> entries will remain in the hash map.
> I'm not going any further, before your feedback.
> Cheers,
> -----Message d'origine-----
> De : Matthew Adams [mailto:matthew@matthewadams.org]
> Envoyé : mardi 30 octobre 2007 19:09
> À : Apache JDO project; JDO Expert Group
> Objet : #key and #value in query filter?
> Hi all,
> I just proposed in JPA on the thread for support for Maps that JPAQL
> support "#key" and "#value" for navigation through maps, much like we
> can use "#key" and "#value" to define fetch groups in JDO.  I took
> for granted that these expressions can be used in JDOQL, and after a
> search through the spec, I don't see where they can.  I only see the
> list of supported Map and Collection methods in 14.6.2, "Filter
> specfication".
> One of the JPA examples in the proposal looks like the following:
> SELECT im#value
> FROM Item i JOIN i.images im
> WHERE im#key in ('thumbnail', 'full', 'high-res')
> First, what would the equivalent JDOQL for this be?
> Second, what are your thoughts on JDOQL support for "#key", "#value"
> and "in"?  This would allow us to write the following.  This is
> decidedly not very Java-like (a design goal of JDOQL), so this would
> be a bit of a departure from tradition for JDOQL.
> -matthew

View raw message