We released a version of most of these in the search API:
https://developers.google.com/appengine/docs/python/search/
We also released open source code that can be used to do the last two
https://code.google.com/p/s2-geometry-library-java/
That being said, we are still planning to make these first
*):
class DynamicEntity(db.Expando):
@classmethod
def _get_kind(cls):
return 'MyCustomEntity'
newEntity = DynamicEntity()
newEntity.fname = Test
newEntity.put()
On Friday, October 11, 2013 11:39:43 AM UTC+5:30, Alfred Fuller wrote
FYI, the following function should be sufficient to register a dynamic kind
in the kind_map:
def addExpandoForKind(kind):
class Dummy(db.Expando):
@classmethod
def _get_kind(cls):
return kind
though it is not a good solution :-) (there are all sorts of memory,
thread and request
DynamicEntity(db.Expando):
@classmethod
def _get_kind(cls):
return 'MyCustomEntity'
newEntity = DynamicEntity()
newEntity.fname = Test
newEntity.put()
On Friday, October 11, 2013 11:39:43 AM UTC+5:30, Alfred Fuller wrote:
FYI
:30, Alfred Fuller wrote:
FYI both ndb and db support dynamic properties through the Expando class
On Wed, Oct 9, 2013 at 5:36 PM, Vinny P vinn...@gmail.com wrote:
On Wed, Oct 9, 2013 at 8:32 AM, Mitul Golakiya mtl.go...@gmail.**com
wrote:
We are using datastore.py for querying data from
FYI both ndb and db support dynamic properties through the Expando class
On Wed, Oct 9, 2013 at 5:36 PM, Vinny P vinny...@gmail.com wrote:
On Wed, Oct 9, 2013 at 8:32 AM, Mitul Golakiya mtl.golak...@gmail.com
wrote:
We are using datastore.py for querying data from datastore, because we
2^53 is the largest exact *integer* value representable by a 64-bit *float*
*
*
scattered ids are guaranteed to be representable by a 64-bit float which
means they are less than or equal to 2^53.
On Fri, Jun 14, 2013 at 11:12 AM, Nico Verwer nver...@gmail.com wrote:
I should have said: 2^53 is
A Java long is a 64-bit integer and the correct primitive to store an ID in.
On Thu, Jun 13, 2013 at 2:15 AM, jon jonni.g...@gmail.com wrote:
Also, in response to Ray and Timh regarding integer data types: although
the new auto ids will be too large to store in 32-bit integers, javascript
The dev app server populates the scatter index at 50% as it is assumed to
have much less data.
On Tue, May 22, 2012 at 8:18 PM, Kaan Soral kaanso...@gmail.com wrote:
Unfortunately I didn't get the chance to, probably should set a dummy
project and code etc for this kind of stuff
I decided
Backwards paging is currently supported, you can see this ndb example of
how to do it:
https://developers.google.com/appengine/docs/python/ndb/queries#cursors
On Wed, Oct 10, 2012 at 12:29 AM, Matija matija.jerko...@gmail.com wrote:
Hey,
is there any news about backwards cursor? Two years ago
matija.jerko...@gmail.com wrote:
Also in Java API?
On Monday, October 22, 2012 8:33:00 PM UTC+2, Alfred Fuller wrote:
Backwards paging is currently supported, you can see this ndb example of
how to do it: https://developers.google.**com/appengine/docs/python/ndb/*
*queries#cursorshttps
13, 2012 4:43:05 PM UTC-7, Alfred Fuller wrote:
It is possible that command line tool gave up too soon and it just taking
longer than normal to deploy the new app version. In this case the version
should show up in your admin console.
On Thu, Sep 13, 2012 at 4:20 PM, Trevor Reid trevor
On Thu, Sep 13, 2012 at 9:19 AM, gks liu...@gmail.com wrote:
With the introduction of OR query, GAE SDK 1.7+ marks Query.setFilter as
deprecated so that upgrading to 1.7 will lead to a lot of warnings in my
project. Is backward compatibility guaranteed in 1.7.1 with those warning?
The
to create a new
environment and try to deploy a sample app there.
On Thursday, September 13, 2012 11:35:21 AM UTC-7, Alfred Fuller wrote:
On Thu, Sep 13, 2012 at 9:19 AM, gks liu...@gmail.com wrote:
With the introduction of OR query, GAE SDK 1.7+ marks Query.setFilter
as deprecated so
Are you using the low level API? Can you give me the .toString() of the
query?
On Tue, Aug 21, 2012 at 9:20 AM, Oleg Bashtenko o...@cloudwk.com wrote:
Got another problem.
There is a Ticket kind in my datastore. I want to run a search query on
a several fields, e.g.: { active, technicianKey,
it?
On Monday, March 14, 2011 6:52:55 PM UTC+1, Alfred Fuller wrote:
Batch put is not atomic. When using a batch put across entity groups it
is very important to make sure the operation is idempotent (for example by
not using auto id allocation) as retrying a failed batch put may produce
duplicate
True, thx takashi.
On Thu, Jun 28, 2012 at 7:36 AM, Takashi Matsuo tmat...@google.com wrote:
Currently, it's the latter for now, and billed per sub-query. We're
building something better than the current implementation(as always).
-- Takashi
On Thu, Jun 28, 2012 at 1:17 AM, Joakim
It doesn't use the datastore or charge datastore ops/storage.
On Jun 22, 2012 6:09 PM, Waleed Abdulla wal...@ninua.com wrote:
I wonder if the task queue is using the datastore behind the scenes and
the cost of those calls are included in the datastore quota? Have you
checked to see if using
App Engine handles index building for you. When you add a new index, it
will re-index all entities.
However, it is possible to save entities with an 'unindexed' property, then
change the model definition to save the same property but 'indexed.' In
this case, the old entities will remain
explanation.
The other thing to check would be if the missing records have values for
the properties specified in the projection.
Rgds
T
On Tuesday, June 19, 2012 10:35:32 PM UTC+8, Christopher Ramírez wrote:
Yes it happens on both servers.
On Monday, June 18, 2012 11:01:08 AM UTC-6, Alfred
Does this happen in both the dev_appserver and production?
On Fri, Jun 15, 2012 at 10:28 AM, Christopher Ramírez
blindedbythed...@gmail.com wrote:
I was trying to use projection queries, but I had extrange issues using
them.
I'm trying to use them like this:
offset_group = Clients.all(
We are working hard on improving the built-in backup experience, but in the
meantime:
The datastore admin is open source so you can make the backup MR do what
every you want:
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/ext/datastore_admin/backup_handler.py
= field1_new_value
s.field2 = field2_new_value
s.field3 = field3_new_value
s.put()
And datastore will check which fields were changed, only update those
fields and their indices?
On Saturday, September 24, 2011 1:00:44 PM UTC-7, Alfred Fuller wrote:
Yes, the write ops for changing an entity depends
We have found and fixed the problem (it was a utf-8 encoding issue with the
blob metadata). If you try again it should work. Thanks for your patients.
On Sat, Apr 14, 2012 at 6:52 AM, Lucian Baciu lucianba...@gmail.com wrote:
I'm trying to migrate my app (id: timetonote) to HRD. However, it
I agree :-), the doc update is in progress.
On Tue, Apr 24, 2012 at 10:41 PM, Sun Jing kea...@gmail.com wrote:
Thank you, it works. I think the document should be updated:
https://developers.google.com/appengine/docs/python/datastore/queryclass#Query_get
--
You received this message
Projection queries return the properties you projected and key for each
entity that matches the query.
On Wed, Apr 25, 2012 at 10:39 AM, pdknsk pdk...@googlemail.com wrote:
When using projection queries for just a single property, does this
also return keys? The answer is probably yes, as
ndb does not yet officially support projection queries, so there might be
some rough edges if you use them.
On Apr 25, 2012 1:23 AM, Gopal Patel patelgo...@gmail.com wrote:
does ndb supports projection query ?
On Wed, Apr 25, 2012 at 11:43 AM, Alfred Fuller arful...@google.comwrote:
I agree
('title') is not a tuple, you need to use ('title',) or ['title'] instead
print ('title')
title
print ('title',)
('title',)
On Tue, Apr 24, 2012 at 8:58 PM, Sun Jing kea...@gmail.com wrote:
I tried to use projection queries:
class Article(db.Model):
title =
Oh, also db.Query takes a class not a string, should be:
db.Query(Article, projection=('title',)).get()
On Tue, Apr 24, 2012 at 9:09 PM, Alfred Fuller arful...@google.com wrote:
('title') is not a tuple, you need to use ('title',) or ['title'] instead
print ('title')
title
print ('title
?
On Wed, Apr 25, 2012 at 12:53 PM, Alfred Fuller arful...@google.comwrote:
Oh, also db.Query takes a class not a string, should be:
db.Query(Article, projection=('title',)).get()
On Tue, Apr 24, 2012 at 9:09 PM, Alfred Fuller arful...@google.comwrote:
('title') is not a tuple, you need to use
For now you have to hunt around in the doc string, look for projection
near query objects :-).
On Sat, Apr 21, 2012 at 11:13 AM, Nathaniel Stensland
nstensl...@gmail.comwrote:
How to find out more about
- You can now perform datastore queries that return a subset of your entity
properties
She means the app engine Mail API:
http://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/api/mail/
javax.mail is not supported.
On Fri, Apr 20, 2012 at 5:06 AM, Emanuele Ziglioli
theb...@emanueleziglioli.it wrote:
Hi Christina,
I'm using the mail
Hmm, I think I may be completely wrong :-)
https://developers.google.com/appengine/docs/java/mail/overview
On Fri, Apr 20, 2012 at 7:55 AM, Alfred Fuller arful...@google.com wrote:
She means the app engine Mail API:
http://code.google.com/p/googleappengine/source/browse/trunk/java/src/main
It looks like the problem might be: Do not add Oracle®'s JavaMail JARs to
your app; if you do, the app will throw exceptions. I see a bunch of
com.sun.mail.smtp...
in the stack trace.
On Fri, Apr 20, 2012 at 8:01 AM, Alfred Fuller arful...@google.com wrote:
Hmm, I think I may be completely
Ya, this is a pickling issue, we have created a fix for it and will deploy
it soon. In the mean time, recreating any queries that were pickled using
the 1.6.4 runtime will fix this problem.
On Wed, Apr 18, 2012 at 8:25 PM, Amy Unruh a...@google.com wrote:
Try clearing memcache from the admin
Is query a db.GqlQuery or a db.Query?
In either case you can use:
query.run(keys_only=True) # works for fetch and get as well
On Wed, Apr 18, 2012 at 2:48 PM, Jason Collins jason.a.coll...@gmail.comwrote:
This is almost certainly due to a change in a protected attribute on
the Query class
Should work for everything, if not, let me know :-)
On Wed, Apr 18, 2012 at 2:55 PM, Jason Collins jason.a.coll...@gmail.comwrote:
Will this work for MultiQuery too?
j
On Apr 18, 3:50 pm, Alfred Fuller arful...@google.com wrote:
Is query a db.GqlQuery or a db.Query?
In either case you
. Could be that this is supported under
1.6.5, but we're in an in-between stage at the moment...
BadRequestError: keys only queries are not supported by multi-query.
j
On Apr 18, 3:56 pm, Alfred Fuller arful...@google.com wrote:
Should work for everything, if not, let me know :-)
On Wed
It looks like you have a very large number of namespaces. This is a known
issue with the GAE MR framework, we are looking into using an alternate
approach to migrate your app.
On Wed, Apr 11, 2012 at 6:52 AM, Aswath Satrasala
aswath.satras...@gmail.com wrote:
Hello Chris,
The HRD migration is
Migrating all data is supported already (unless I am missing something).
Does it say otherwise somewhere?
On Mon, Apr 9, 2012 at 12:15 PM, andrew andrew.macken...@bcntouch.comwrote:
Hi Chris,
Migrating all data from all namespaces (I.e. a transparent migration of
all data that is then
We've already lasted 4 years, which makes us an outlier in your list :-).
On Thu, Apr 5, 2012 at 4:16 PM, Andrei gml...@gmail.com wrote:
will gae last 3 years?
google wave, google buzz, ... gae?
On Apr 4, 11:20 pm, Andrei gml...@gmail.com wrote:
3 years from now?
On Apr 4, 4:42 pm,
It seems like there are two separate issues here:
We have a bug where the index quota isn't being updated correctly (we are
looking into this).
When you have a lot of kinds you may actually need a lot of indexes. For
example 200 indexes / 50 kinds = 4 indexes per kind. This is reasonable. I
What is your app id?
Did you perform a lot of queries using remote api?
On Tue, Mar 6, 2012 at 4:40 PM, Dave Peck davep...@gmail.com wrote:
My production application went over its daily budget today. Let's just
say that my daily budget is roughly 3x what I've ever actually needed
on my
We currently have no plans to expand the feature set of the migration tool
to fit alternative use cases.
That being said, the datastore admin page does provide a copy to app
feature that should come close to meeting the needs of your use case. You
can also use datastore triggers (
Did you alias your old app id to your new app id? Cause if that is the
case, then remote_api is likely talking to the new app (and I don't think
it is possible to make it talk to the old app).
On Mon, Dec 12, 2011 at 9:56 AM, MikeR mike.ross...@gmail.com wrote:
Hi Simon,
Thanks for the reply;
The new pricing model has always included count() and our accounting code
didn't change at launch. What is your app id so I can take a deeper look?
On Sat, Nov 26, 2011 at 3:14 AM, Millisecond millisec...@gmail.com wrote:
It appears that on the same day billing was enabled (Nov 7th), what
, 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
On Nov 17, 5:23 am, Alfred Fuller arfuller+appeng...@google.com
wrote
/getting_the_most_out_of_spring_and_app_engine_springone_2011.pdf
On page 51, regarding the advanced query planner you can read No more
'needs index' errors (although some may timeout).
I thought and hoped no more need for managing indexes manually ..
Cheers
Mos
On Tue, Nov 15, 2011 at 6:46 PM, Alfred
On Wed, Nov 9, 2011 at 1:42 AM, Mos mosa...@googlemail.com 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.
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 query
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 1.6.0
full_app_idhttps://cs.corp.google.com/#google3/apphosting/api/app_identity/app_identity.pyct=xref_usagesgs=py:google3.apphosting.api.app_identity.app_identity.get_application_idamp;full_app_id:google3/apphosting/api/app_identity/app_identity.pyl=336gsn=full_app_id=
not using environment variables there)?
On Nov 13, 2011, at 2:54 PM, Alfred Fuller wrote:
full_app_idhttps://cs.corp.google.com/#google3/apphosting/api/app_identity/app_identity.pyct=xref_usagesgs=py:google3.apphosting.api.app_identity.app_identity.get_application_idfull_app_id:google3/apphosting/api
Can you be more specific about what extra entities are actually being
written. The SDKs now split batch get/delete/puts, are you sure you aren't
just seeing that?
On Tue, Nov 8, 2011 at 9:02 AM, Alexis alexis.hanico...@gmail.com wrote:
I've got a small issue with this release:
the development
Here is an article that can help you reduce the # of composite indexes you
use in some cases:
http://code.google.com/appengine/articles/indexselection.html
On Tue, Nov 8, 2011 at 4:16 PM, Jeff Schnitzer j...@infohazard.org wrote:
FWIW, your app would have been a problem under the old pricing
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 matt...@jaggard.org.ukwrote:
Regarding the index selection shown here:
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
Wait, are you comparing the old pricing model or the new pricing model
(since you attributed the cost to writes I just assumed you were talking
about the new pricing model)? In the old pricing model HRD writes cost more
(~3x).
On Fri, Oct 21, 2011 at 8:18 AM, Jason Collins
On Tue, Oct 11, 2011 at 8:50 AM, Edward Hartwell Goose
ed.go...@gmail.comwrote:
Hi,
I'm trying to work out why some indexes I've got have gone into an error
state.
My interpretation of the help text (
:
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 Fuller
arfuller+appeng...@google.com wrote:
I believe (you
There is no difference between M/S and HRD with regards to write ops (i.e.
given the same input, M/S and HRD report the exact same amount of writes).
Something else must be different (traffic, existing entity values, etc).
On Tue, Oct 18, 2011 at 12:46 PM, Jason Collins
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
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
It will only suggest better indexes in some cases (specifically the cases
where the same property was repeated in multiple equality filters, e. g.
WHERE tag=:1 AND tag=:2 ORDER BY date)
On Wed, Sep 28, 2011 at 1:53 PM, jay kyburz@gmail.com wrote:
Thanks for the reply Jason.
So you are
Yes, the write ops for changing an entity depends on how many indexed
properties you change. It is:
1 op for the entity
2 ops for each changed index value (1 to remove the old value and 1 to add
the new)
Since it is not a fixed value and depends on what you actually modify, we do
not (can not)
An interesting notion. Although you could also just
use ColorThings(key_name=color) as the parent entity for all the Things.
This way the list of things would be queriable directly (using
an ancestor query) and there would not be a limit on the number and size of
Things. They also exist next to
Ikai is correct to think about replication in this case. In a single replica
you could have one of three states:
Applied - fully visible
Committed - has the log entry, but has yet to apply it
Missing - the log entry has yet to be replicated
Only in the first case is it visible to a global query.
is None at that point. Something very strange
is happening there.
Bye,
Waldemar
On Tue, Sep 6, 2011 at 11:20 PM, Alfred Fuller
arfuller+appeng...@google.com wrote:
Hmm. I have seen it work this way on my system. This is the function you
need have
invoked
http://code.google.com/p
and a persistent-across-runs
datastore is a nightmare. I can't believe I'm they only one running into
this problem.
-Joshua
On Sep 7, 2011, at 1:45 PM, Alfred Fuller wrote:
Seems like we have to come up with a better solution. We will look into it.
For now you can still call Flush() manually
Ok, this is a very different problem then.
Here is the function that reads the data:
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/api/datastore_file_stub.py#444
Here is the function that writes the data:
We were able to reproduce it. Something strange is going on. I'll let you
know what we figure out.
On Wed, Sep 7, 2011 at 2:03 PM, Alfred Fuller arfuller+appeng...@google.com
wrote:
Ok, this is a very different problem then.
Here is the function that reads the data:
http://code.google.com/p
!
On Wed, Sep 7, 2011 at 2:53 PM, Alfred Fuller arfuller+appeng...@google.com
wrote:
We were able to reproduce it. Something strange is going on. I'll let you
know what we figure out.
On Wed, Sep 7, 2011 at 2:03 PM, Alfred Fuller
arfuller+appeng...@google.com wrote:
Ok, this is a very
If the dev_appserver is shut down gracefully, then you should not see this
problem (as of 1.5.3).
On Tue, Sep 6, 2011 at 8:40 AM, Joshua Smith joshuaesm...@charter.netwrote:
When I start with --high_replication to test on the dev appserver, I alway
seem to be starting with a blank database.
, Joshua Smith joshuaesm...@charter.netwrote:
I've updated to 1.5.3, but I still have this problem.
How do I shut down gracefully? I'm shutting down by pressing the big red
STOP button on the launcher.
Is there another way?
-Joshua
On Sep 6, 2011, at 12:51 PM, Alfred Fuller wrote
, at 1:22 PM, Alfred Fuller wrote:
Apparently not. I believe running the dev_appserver on a command line and
hitting Ctrl-C will work. The trick is to have the datastore stub's
destructor invoked, which doesn't happen if the app is hard stopped. You can
also call Flush() on the stub manually
.
Note that ^C sends sigINT which is the same thing the STOP sign on the
launcher sends.
On Sep 6, 2011, at 1:45 PM, Alfred Fuller wrote:
You would have to have code that only exists in your dev environment (or
just never gets called in production), that grabs the stub and calls the
function
A datastore write op != an entity put/delete. It is actually (entity +
|index deltas|).
For example if you have a Kind with 3 indexed properties and 1 composite
index the number of write ops to put a new entity would be:
1 entity + 1 kind index + (1 ascending + 1 descending) * 3 indexed
On Sat, Sep 3, 2011 at 8:23 AM, johnP j...@thinkwave.com wrote:
Which leads to a potential constructive suggestion. Maybe Goog can
post a troubleshooting guide that lists different line-items in the
new-style billing, and potential gotchas? An example in your blog is
that sudden
BTW, I really like the blog post Emlyn.
On Sun, Sep 4, 2011 at 11:54 PM, Alfred Fuller
arfuller+appeng...@google.com wrote:
On Sat, Sep 3, 2011 at 8:23 AM, johnP j...@thinkwave.com wrote:
Which leads to a potential constructive suggestion. Maybe Goog can
post a troubleshooting guide
The datastore does not delete things right away. It marks them as delete and
waits for a compaction to actually remove the data. If a lot of data is
deleted at the start of a query, the datastore will have to skip all the
deleted rows until it finds the first real entity. This is what is causing
On Sun, Sep 4, 2011 at 1:31 PM, Volker Schönefeld
volker.schoenef...@gmail.com wrote:
Hey Alfred,
thanks for the reply. I've got a couple more questions regarding the
compaction, I hope you can answer a few:
- When do those compaction events happen?
The process that controls the
Hi,
Under the hood count() runs a keys_only query with an offset of MAX_INT.
This is faster than running a keys only query yourself as it avoids the
transit and serialization costs of returning the keys, however it costs the
same. Unlike a fixed-schema database solution, performing a count in the
On Aug 19, 9:34 pm, Alfred Fuller arfuller+appeng...@google.com
wrote:
Are your transactions idempotent? It is possible that the transaction is
being run (and succeeding) twice in this case. What other request is
colliding with first? You are not using any non-ancestor queries or
setting
Are your transactions idempotent? It is possible that the transaction is
being run (and succeeding) twice in this case. What other request is
colliding with first? You are not using any non-ancestor queries or setting
read_policy=EVENTUAL on any reads correct?
On Fri, Aug 19, 2011 at 12:42 PM,
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 this
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
:-)
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
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 this
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
:-)
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
- 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 means that there are alternatives to using exploding
Datastore transactions
On Wed, Jul 13, 2011 at 2:51 PM, pdknsk pdk...@googlemail.com wrote:
Does transaction refer to database transactions? Or does multiple
concurrent transactions mean asynchronous operations in general? This
is not clear to me. Does it support asynchronous urlfetch now?
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
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
The Datastore itself has always supported multiple concurrent transactions.
However the dev_appserver in the python SDK previously used a global lock
and would deadlock if a single thread tried to start more than a single
transaction. Now you can have multiple concurrent transactions running at
Still working on it :-).
On Fri, Jul 8, 2011 at 3:58 PM, acuth adrian.cuthb...@gmail.com wrote:
...or is it to be superceded by the Full Text Search service they detailed
at Google I/O 2011? http://www.youtube.com/watch?v=7B7FyU9wW8Y
--
You received this message because you are subscribed
On Sat, Jun 25, 2011 at 5:36 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Sat, Jun 25, 2011 at 3:26 PM, Alfred Fuller
arfuller+appeng...@google.com wrote:
This makes sense, and encourages more use of memcache. to hold entities.
One question that I've been wondering a while - presuming
appear
in). Hopefully the new pricing model is clear enough that you don't feel
inclined to dig that deep.
On Sun, Jun 26, 2011 at 12:37 PM, Stephen sdeasey+gro...@gmail.com wrote:
On Sun, Jun 26, 2011 at 5:02 PM, Alfred Fuller
arfuller+appeng...@google.com wrote:
- Additional small op charge
On Fri, Jun 24, 2011 at 4:04 PM, Jeff Schnitzer j...@infohazard.org wrote:
Thanks, this clarifies much! Questions below:
On Thu, Jun 23, 2011 at 11:49 PM, Gregory D'alesandre gr...@google.comwrote:
Datastore APIs Q: Which operations are being charged for?
A: There are 3 categories of
Thanks Robert!
This feature is not an optimization, it is for testing. It allows you to see
ruffly how your application will perform when deployed to an app that is
using the High Replication Datastore. It works by estimating the likelihood
of a write showing up in a global query after some
1 - 100 of 134 matches
Mail list logo
