I figured it might be of value on things like range scans. Think
about uses like this:
SELECT key, first_name FROM People WHERE first_name >= 'alb' AND
first_name < 'ablz';
You could have the entity id _and_ the name from the index. Aside
from this type of use case, you are probably right -- not much value
for equality-only queries.
I'm not sure I see an issue with list properties, wouldn't the
expectation be to only return the matching element?
On Fri, Dec 17, 2010 at 23:43, Tim Hoffman <[email protected]> wrote:
> One major problem I see will be with list properties,
> I assume each value in the list when indexed will have its own position in
> the index along with the Key,
> So if what you describe was implemented you find you could only get a single
> value from the index that matched.
> In fact in all cases you could probably only get properties for matches from
> the index(es) unless you retrieve the whole entity.
> A lazily loaded entity, ie match the entity, get the key, create a lazy
> entity, will still have to fetch the full entity to get any property
> other than those used to find the entity in the indexes.
> I think ;-)
> So I am not sure there is a lot to be gained.
> T
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
