date:20110323

[appengine-java] Re: Set password for appcfg.sh update

2011-03-23 Thread Ian Marshall

Ben,

Have you tried the option(s) (--email and) --passin?

Ian


On Mar 22, 7:08 pm, Benjamin Muschko benjamin.musc...@gmail.com
wrote:
 Hi,

 Is there way to use a pre-defined password (e.g. set as a parameter or
 from some file) for the update task (http://code.google.com/appengine/
 docs/java/tools/uploadinganapp.html)? Unfortunately, I couldn't find
 an appropriate parameter. I'd like to upload my app to App Engine as
 part of an automated Continuous Integration process without having to
 enter the password on the command-line.

 Thanks,

 Ben

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Task Enqueue in a Transaction

2011-03-23 Thread Tom Gibara

That's not how I understood the documentation, and it isn't my
experience either.

http://code.google.com/appengine/docs/java/datastore/transactions.html

This page explicitly states that it's the enqueing of the task which
is subject to the transaction. It says nothing about its execution.
When the task runs, it's free to do what ever work it wants to,
including opening one or more transactions.

I use the same pattern as the OP (except with a transaction around the
get by key), and on the development server at least, it always sees
the latest state of the datastore (post its enqueing transaction).
Unfortunately the code hasn't transitioned to Google's servers for
testing yet.

Tom.

On 23 March 2011 05:26, Didier Durand durand.did...@gmail.com wrote:
Hi,

For me, the answer is here:
http://code.google.com/appengine/docs/java/datastore/transactions.html#Isolation_and_Consistency

They say: Queries and gets inside a transaction are guaranteed to see
a single, consistent snapshot of the datastore as of the beginning of
the transaction. In particular, entities and index rows in the
transaction's entity group are fully updated so that queries return
the complete, correct set of result entities, without the false
positives or false negatives described in Transaction Isolation that
can occur in queries outside of transactions.

The task is part of the initial transaction so it sees the ds as of
the beginning of the transaction

regards

didier

On Mar 22, 9:12 pm, Tom Gibara tomgib...@gmail.com wrote:
Thanks for the link, somehow I'd managed to miss that page of
documentation entirely*; it's good to know, though it indicates other
problems for the OP.

I'm not clear on why eventually consistent gets aren't an option, ie.
why all gets are indicated as being strongly consistent. Is this a
direct consequence of replication algorithm used? There are various
places in the code I'm currently developing where dirty gets are
adequate and I'd be happy to see them faster.

* As an aside, I do find the documentation on the datastore feels very
scattered. I'd much prefer sections on the underlying app engine
mechanics with less language specific guidance.

Tom.

On 22 March 2011 17:59, Jay Young jayyoung9...@gmail.com wrote:

According to the docs, gets, puts, deletes, and ancestor queries are all
strongly consistent:
http://code.google.com/appengine/docs/java/datastore/hr/

--
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.

65 matches

Mail list logo