Ugorji,

I don't know if they will support re-indexing things based on new
index definition, however, I did put in an issue back in August 2009
to be able to create a custom index term on the fly. See if this would
partially solve the issue (again, it doesn't address reindexing
already put entities).

http://code.google.com/p/googleappengine/issues/detail?id=1935

Cheers!

On Mar 18, 10:37 am, Ugorji <[email protected]> wrote:
> +1 big-time on this. With the restriction that every index'able
> property must be indexed at put-time when put into the datastore
> (using setProperty as opposed to setUnindexedProperty), it has 2 MAJOR
> disadvantages with far-reaching repercussions:
>
> - you cannot index entities after they have been put (even with a
> custom index). You will have to re-write the entity to index it.
> - Each put is 4X more expensive in latency/clock-time (potentially),
> CPU-cost and storage. This seems un-necessary, especially if a single
> custom index will suffice all your querying needs.
>
> I was really hoping to use custom indexes to buy major performance
> savings (in latency, CPU-cost and storage), and also be able to re-
> index every entity after the fact. But this restriction is heavy
> (preventing direct solution to a problem everyone may end up facing),
> and very expensive (costing us big-time). Can one of the google guys
> respond to this, before we file a bug?
>
> Thanks.
>
> On Mar 16, 2:07 pm, Jeff Schnitzer <[email protected]> wrote:
>
>
>
> > On Mon, Mar 15, 2010 at 11:04 PM, John Patterson <[email protected]> 
> > wrote:
>
> > > On 16 Mar 2010, at 12:25, Jeff Schnitzer wrote:
>
> > >> I'm puzzled by the behavior of custom indexes.  I have a simple test
> > >> case below, a simple equality filter on one property combined with a
> > >> descending sort on another property.  If I set the properties with
> > >> setUnindexedProperty(), the query fails to find the result.  If I set
> > >> the properties with setProperty(), it does.
>
> > > I also wondered why - I assume that the custom index build reads the 
> > > single
> > > property indexes directly which must be more efficient than reading the
> > > Entities "table".
>
> > I guess that is possible, but seems like a poor design decision.  It
> > makes adding custom indexes after-the-fact really, really painful.
>
> > Can someone official chime in on this?  Is it intended behavior, or
> > should we file an issue against it?  The documentation doesn't say
> > much on the subject, and all the conceptual explanation of queries
> > suggests that these extra single-property indexes will be unused.
>
> > Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" 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-java?hl=en.

Reply via email to