11 at 5:59 PM, Emanuele Ziglioli <
theb...@emanueleziglioli.it> wrote:
> zig zag doesn't work for me, using the Siena API
>
> What's worse, an 'index error' was created and I had to cleanup the
> index error on the production server, a real PITA
>
> O
d for managing indexes manually ..
>
> Cheers
> Mos
>
>
>
> On Tue, Nov 15, 2011 at 6:46 PM, Alfred Fuller <
> arfuller+appeng...@google.com> wrote:
>
>>
>>
>> On Wed, Nov 9, 2011 at 1:42 AM, Mos wrote:
>>
>>> Does the im
The new query planner was actually released in 1.5.4 (the article was the
only thing launched in 1.6.0)
On Thu, Nov 10, 2011 at 11:46 AM, Emanuele Ziglioli <
theb...@emanueleziglioli.it> wrote:
> Bump 2 :-)
>
> I'd be curious to see other people's experience with the new Query
> Planner.
>
> But
This really shouldn't happen, something strange is going on. I need to know
the queries seen by the local development server that are failing and the
indexes you have to debug it.
On Wed, Nov 9, 2011 at 3:02 PM, Emanuele Ziglioli <
theb...@emanueleziglioli.it> wrote:
> So, from what I see, my que
On Wed, Nov 9, 2011 at 1:42 AM, Mos wrote:
> Does the improved query planner reduce the need of managing indexes
> manually in the datastore-index.xml file?
>
It increases the need to manage indexes manually
>
> I'm a bit confused.
> The documentation is not obvious for me.
>
> In local develo
The order of the filters does not have an effect on the performance (the
zigzag algorithm we use does not give preference to any index scans it is
performing).
On Tue, Nov 1, 2011 at 2:45 AM, Matthew Jaggard wrote:
> Regarding the index selection shown here:
> http://code.google.com/appengine/art
The copy MR code is available here:
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/ext/datastore_admin/copy_handler.py
It is not doing anything special, it can be adapted to do what ever you
need. Though it looks like you are a Java programmer (which might make
ng this method:
>
>
> LocalDatastoreServiceTestConfig.setDefaultHighRepJobPolicyUnappliedJobPercentage(100)
>
> commit() always produces this:
>
> java.lang.IllegalArgumentException: transactions on multiple entity
> groups only allowed in High Replication applications
>
> :-(
>
> Jeff
>
> On Tue, Oct 18, 2011 at 1:44 PM, Alfred Fulle
I believe (you should test this) that it won't do any harm to set XG=true in
master slave (it will just ignore you).
On Tue, Oct 18, 2011 at 1:28 PM, Jeff Schnitzer wrote:
> On Tue, Oct 18, 2011 at 9:07 AM, David Gay (Google)
> wrote:
> >
> > One other consideration: XG transactions do not work
XG transactions will have no effect on global queries, as
the fundamental problems still remains (namely that it is impossible to know
what entity groups will/should appear in a global query). Additionally you
should not use this read_policy, it has little effect in M/S and no effect
in HRD.
On W
:-)
performance is data dependent.
Here is convoluted explanation of performance:
Sx = set of entities where list = :x
smallest_set = min(S1.size(), S2.size(), ...)
It works best when the intersection(S1, S2, S3,...) is large compared to the
smallest_set.
The pathological case is intersection(S1
Yes, you are correct and those indexes will work. It's a trade of, composite
indexes 'pre-intersect' (at write time) properties while zigzag merge join
'post-intersects' properties (at read time). I left the ancestor in because
it is probably very 'selective' which has the potential to greatly redu
On Fri, Jul 15, 2011 at 12:25 AM, Alexandru Farcaş <
alex.far...@expert-group.biz> wrote:
> Hi Alfred,
>
> Thanks for clarification. I also have 2 questions:
>
> 1. For this query:
> SELECT * FROM Model WHERE list = :1 AND list =:2 AND list=:3 AND string :=4
> ORDER BY date DESC
> will be enough
name: list1
- name: int
- name: date
direction: desc
- kind: Model
ancestor: yes
properties:
- name: list2
- name: int
- name: date
direction: desc
- Alfred
On Tue, Jul 12, 2011 at 4:34 PM, Alfred Fuller <
arfuller+appeng...@google.com> wrote:
> Hi,
>
> It me
Hi,
It means that there are alternatives to using exploding indexes (i.e. they
are no longer required to execute a given query). You can still have them
(there are cases where they are useful, namely to optimize query speed over
write cost) and the SDK will still suggest them in many cases (as it
Currently hasNext() will block on the first batch of results. There is
currently no way to do what you are asking in Java.
On Tue, Dec 7, 2010 at 2:40 AM, Maxim Veksler wrote:
> Hi Max,
>
> Could you please provide input on the following design:
>
> We design for DataSource redundancy. For this
Hi,
The default limit is still 1000, you need to set you're own limit in order
to exceed the default (in fact countEntities() has been deprecated
to encourage you to do this). Here are some examples:
query.countEntities(withLimit(5000)); // limit of 5000
query.countEntities(withDefaults()); // no
On Sat, Aug 7, 2010 at 6:18 PM, Philip Tucker wrote:
> I've just started getting the following error on my server. This query
> had been working fine for months, and I haven't changed the indexes
> lately. Are there some indexes that just buckle under heavy load or
> larger data sets? This partic
What query are you running that produces this exception?
On Sun, Aug 1, 2010 at 8:06 AM, Erencie wrote:
> I think someone has posted this before but the post is not written in
> English so I don't understand.
>
> I tested thoroughly in my local machine and there is no problem in
> persisting one
This can happen when you add the same entity to the put(or delete) request
more than once (same by .equals). If this is the case, your put actually
succeeded. This should be fixed soon, however I would suggest checking your
code to figure out why you are putting the same entity multiple times (if i
This isn't a bad solution, but it has several problems:
- It doesn't scale
- Cache could have holes. I guess then you could grab a query and
scroll though the first 20 pages to fill out the cache. You could
actually start at the highest cursor before the requested page and
page forward to fill ou
For most queries the process goes something like this:
Index Scan -> Fetch Entity -> Send to user
For any query with a sort order or inequality filter on any property
other than __key__ we are still actually fetching the entity in the
datastore, so the only savings is the serialization and transm
22 matches
Mail list logo
