[google-appengine] Max-age less than specified in app.yaml

[Anders]

When the expiration attribute is set in the app.yaml file then the
Cache-Control header still has a max age of 600 seconds.

For example expiration 1 day in app.yaml:

- url: /static/images
  static_dir: static
  expiration: "1d"

Will result in the response:

Date: Fri, 14 Nov 2008 07:25:34 GMT
Expires: Fri, 14 Nov 2008 07:35:34 GMT
Cache-Control: public, max-age=600
Content-Type: image/gif
Server: Google Frontend
Content-Length: 760
Connection: Close

Shouldn't the correct max-age for Cache-Control in this case be 86400
(number of seconds in 1 day)?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Password filed in form

[Alexander Kojevnikov]

Here's a dpasted version of the code:
http://dpaste.com/hold/90657/

> Password field can be created with this code:

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Password filed in form

[Alexander Kojevnikov]

I strongly suggest you not to re-invent the wheel, there are just too
many security issues to take care of if you decide to code
authentication yourself.

django.contrib.auth is your friend:
http://docs.djangoproject.com/en/dev/topics/auth/

app-engine-patch can help you get it running on appengine:
http://code.google.com/p/app-engine-patch/wiki/CustomUserModel

See also this thread:
http://groups.google.com/group/google-appengine/browse_thread/thread/6d04d8b69e89d361/641e9565b6ad7071

Password field can be created with this code:

password = forms.CharField(label='Current password',
max_length=100,
   required=False,
   widget=forms.PasswordInput
(render_value=False))

It works with Django 1.0, I'm not sure about 0.96 which is built into
appengine by default.

--
www.muspy.com

On Nov 14, 2:32 pm, pran__ <[EMAIL PROTECTED]> wrote:
> Hi,
> I don't want my users to compulsorily have a Google account. Yesterday
> i was creating a very simple login page for my app. And i was stuck at
> creating a password field. I have a Model User, which when simplified
> looks like
>
> class User(db.Model):
>     "The User Class"
>     PersonId = db.ReferenceProperty(Person)
>     userName = db.StringProperty(required=True)
>     password = db.StringProperty(required=True)
>     email = db.EmailProperty(required=False)
>     status = db.StringProperty(required=True,  choices =
> ( 'Active','Suspended','Deleted', ))
>
> Now i need to create a login/ new user form/ update profile pages,
> which all require a password box. I have been creating forms from the
> dbModel using google.appengine.ext.db.djangoforms. Can anyone tell me
> how do i create a password widget?
>
> Now the element of surprise. Yesterday i discussed this in IRC
> Channel, and appengineers out there were clueless what happened. I
> searched this group with the keyword 'password' and i got 1 result,
> and that too suggesting me to use google account. Is my app the only
> one that will be using authentication methods apart from the google
> account(if this question is answered by someone) !!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: PyOpenGl

[Hugo]

PyOpenGL is a library to access the OpenGL API locally on your
personal computer. AppEngine is for remote applications running on
servers. With a typical web browser, PyOpenGL on GAE (on the server)
won't help you. You would want to run client-side code to do 3D work.

HTH,
Hugo


On Nov 13, 3:33 pm, Kieran <[EMAIL PROTECTED]> wrote:
> Hi
> I am thinging about putting a 3d interactive program on GAE, where the
> user could rotate a 3d cube etc, as part of a uni project.
> Does anyone have any thoughts on if i could do this by imbedding a
> window in the web page and code the cube in PyOpenGl? Would i have to
> upload the PyOpenGl libraries or is there support for them?
> I'm really only just starting out on this so if anyone has any
> thoughts or experience with something simular that would be good!
> Cheers
> Kieran

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Password filed in form

[pran__]

Hi,
I don't want my users to compulsorily have a Google account. Yesterday
i was creating a very simple login page for my app. And i was stuck at
creating a password field. I have a Model User, which when simplified
looks like

class User(db.Model):
"The User Class"
PersonId = db.ReferenceProperty(Person)
userName = db.StringProperty(required=True)
password = db.StringProperty(required=True)
email = db.EmailProperty(required=False)
status = db.StringProperty(required=True,  choices =
( 'Active','Suspended','Deleted', ))


Now i need to create a login/ new user form/ update profile pages,
which all require a password box. I have been creating forms from the
dbModel using google.appengine.ext.db.djangoforms. Can anyone tell me
how do i create a password widget?

Now the element of surprise. Yesterday i discussed this in IRC
Channel, and appengineers out there were clueless what happened. I
searched this group with the keyword 'password' and i got 1 result,
and that too suggesting me to use google account. Is my app the only
one that will be using authentication methods apart from the google
account(if this question is answered by someone) !!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: simulating login using webtest

[Sudhir]

and put up the code on 
http://corn.appspot.com/2008/11/Simulating-login-with-webtest
in case anyone is interested.

On Nov 12, 9:20 am, Sudhir <[EMAIL PROTECTED]> wrote:
> Well, I managed to figure it out myself :-/
>
> Just stub out users.get_current_user = lambada usr = '[EMAIL PROTECTED]':
> return usr
> before you run the tests. You can also extract it out into a method to
> make things easy.
>
> On Oct 21, 9:28 am, Sudhir <[EMAIL PROTECTED]> wrote:
>
> > Does anyone know how to simulate login using webtest? I've tried
> > doing
>
> > app.get('/_ah/login?action=Login&[EMAIL PROTECTED]')
>
> > but its doesn't register the user as logged in when using webtest.
>
> > Sudhir
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] sdk download problem

[lws68825]

I tried to download the latest appengine sdk 1.1.5. but the download
always stopped at the 82% point of the process.
Can someone help me?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: SproutCore app on AppEngine, authentication concerns

[Devraj Mukherjee]

Appreciate it Charles.

Will yell out on the list if I run into any troubles.

On Fri, Nov 14, 2008 at 4:23 AM, Charles Jolley <[EMAIL PROTECTED]> wrote:
>
> Hi Devraj,
>
> You can setup a proxy from sc-server to your AppEngine.  This way you
> can visit localhost:4020 and you should be able to work from there.
> You can find the samplecode for http://sproutcore-demo.appspot.com at:
>
> http://github.com/sproutit/samples-todos/tree/step-6
>
> Look the servers/sproutcore-demo directory for the AppEngine code.
> There is also a Merb server in there.  The rest is SproutCore code.
>
> -Charles
>
> On Nov 13, 2:00 am, "Devraj Mukherjee" <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> Our app engine application is going to use SproutCore as its
>> JavaScript framework. As SproutCore or JavaScript sits quite
>> independently of App Engine or any server side technology we are
>> assuming that this should work 
>> (actuallyhttp://sproutcore-demo.appspot.com/confirms that it should not be a
>> problem).
>>
>> Authentication should be quite simple as well, as long as both our
>> HTML/JS deliver and REST services use Google authentication its should
>> all work fine.
>>
>> The question is while developing the SproutCore application we need to
>> run two dev servers, so if our rest services required authentication
>> and we deliver our SproutCore app from the SC dev server how can we
>> test that everything works? Although the two dev servers are running
>> at different ports do they still honour the cookies set by the domain
>> (localhost)?
>>
>> Our application is user centric so we will require the user to login.
>>
>> Any SproutCore / App Engine developers out there that could give me a
>> few pointers?
>>
>> Thanks for your time.
>>
>> --
>> "I never look back darling, it distracts from the now", Edna Mode (The
>> Incredibles)
>
> >
>



-- 
"I never look back darling, it distracts from the now", Edna Mode (The
Incredibles)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: 有个想法，想写 个工具帮助自动生成AppEngine的项目文件

[A . TNG]

2008/11/13 A. TNG <[EMAIL PROTECTED]>:
> Hi,
>
> Sorry guys. Make a mistake and send to wrong email address.
>
> --
> Best Regards,
> TANG Jiyu
>

Hi Guys,

I made a mistake and send email to the wrong email address. Please
forget about this thread and do not reply it again.

Thanks in advance.

-- 
Best Regards,
TANG Jiyu (Blog: http://jiyu.wordpress.com.cn)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: PyOpenGl

[Edmar Ferreira]

If PyOpenGl have C modules don't will work.

2008/11/13 Kieran <[EMAIL PROTECTED]>

>
> Hi
> I am thinging about putting a 3d interactive program on GAE, where the
> user could rotate a 3d cube etc, as part of a uni project.
> Does anyone have any thoughts on if i could do this by imbedding a
> window in the web page and code the cube in PyOpenGl? Would i have to
> upload the PyOpenGl libraries or is there support for them?
> I'm really only just starting out on this so if anyone has any
> thoughts or experience with something simular that would be good!
> Cheers
> Kieran
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] PyOpenGl

[Kieran]

Hi
I am thinging about putting a 3d interactive program on GAE, where the
user could rotate a 3d cube etc, as part of a uni project.
Does anyone have any thoughts on if i could do this by imbedding a
window in the web page and code the cube in PyOpenGl? Would i have to
upload the PyOpenGl libraries or is there support for them?
I'm really only just starting out on this so if anyone has any
thoughts or experience with something simular that would be good!
Cheers
Kieran

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: ReferenceProperty could avoid unnecesary resolve

[Andy Freeman]

There are ways to get the key from a db.ReferenceProperty without
fetching the entity from the datastore.

I posted a metaclass that generated {name}_key fields for
db.ReferenceProperty s named {name}.

Also, there's get_value_for_datastore.

class A(db.Model):
pass

class B(db.Model):
a = db.ReferenceProperty(A)

a = A()
a.put()
b = B()
b.a = a.key()
assert a.key() == B.a.get_value_for_datastore(b)


On Nov 13, 7:42 am, tigrillo <[EMAIL PROTECTED]>
wrote:
> For the sake of efficient, it will be nice if ReferenceProperty let's
> us return the Key optionally instead of the Entity.
>
> Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Saving files in Google app engine

[ctran]

No file access is allowed.   You have to use the datastore API to
store it.

On Nov 13, 2:59 pm, jens <[EMAIL PROTECTED]> wrote:
> Hello!
>
> Would it be possible to save files from a web page in the app engine?
> If i have a html form and enter som text is it then possible to save
> that text to a file on my local drive?
>
> Thanks!
>
> /J
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: weird/interesting "multiple entity groups" case

[Jay Freeman (saurik)]

WHAT?!? Frowny /pants/. The whole point of creating this model is that I don't 
have any way to actually look up the Account by key (you will note that I 
create it without passing any specific key_name/id arguments, although I guess 
I could have been sneaking them in through **kw). Specifically, I was trying to 
do something intelligent to get around the "user accounts system is next to 
useless, long term" problem brought up in the thread "Permanent Unique User 
Identifier".

Regardless, thanks. This was incredibly helpful. I think I'm just going to give 
up on Google's user authentication API and code up something with OpenID. The 
Google user authentication thing doesn't even work correctly on an iPhone 
anyway (it breaks horribly if you put in an incorrect password, and it always 
says New Service instead of your application name), and it doesn't even support 
logging out, so it was kind of stupid for me to be trying to rely on it anyway.

-J



From: Charles Srisuwananukorn 
Sent: Thursday, November 13, 2008 9:38 AM
To: google-appengine@googlegroups.com 
Subject: [google-appengine] Re: weird/interesting "multiple entity groups" case


I was seeing this in my app too. The get_by_key_name on line 134 is actually 
getting a different GoogleUser than the one put in on line 144.

The full key of an entity includes the key names for each of its ancestors back 
to some root entity, meaning two entities of the same kind can have the same 
key name if they have different parents. From the docs:


The keys of two different entities can have similar parts as long as at least 
one part is different. For instance, two entities can have the same kind and 
name if they have different parents. 
(http://code.google.com/appengine/docs/datastore/keysandentitygroups.html)


So the get_by_key_name below is fetching a GoogleUser whose key name matches 
the value of "hash" and has no parents. To get the right GoogleUser, you'd need 
to use 


GoogleUser.get(Key.from_path('Account', , 
'GoogleUser', hash))


where you specify either the ID or the key name of the account as well.

Hope that helps.

--Charles


On Thu, Nov 13, 2008 at 3:21 AM, Jay Freeman (saurik) <[EMAIL PROTECTED]> wrote:

  I am  running into a confusing "can't operate on multiple entity groups in a 
single transaction" case when I am, in fact, not accessing "multiple entity 
groups". I think I understand what might be going on, but A) am not certain and 
B) others might find it interesting, anyway.

  What is happening is that I have a transaction that is operating over two 
models: GoogleUser and Account. I get the GoogleUser instance associated with 
the current e-mail address with get_by_key_name and then return gooser.account. 
If I fail to find that GoogleUser, I add a new Account, and into the /same 
entity group/ I add the GoogleUser in question.

  For reference, here is the actual code of my transaction:

  132 @staticmethod
  133 def goi_account_by_primary_key_(user, hash, **kw):
  134 gooser = GoogleUser.get_by_key_name(hash)
  135 if gooser:
  136 account = db.get(gooser.account)
  137 keys = kw.keys()
  138 for key in keys:
  139 setattr(account, key, kw[key])
  140 account.put()
  141 else:
  142 account = Account(**kw)
  143 account.put()
  144 gooser = GoogleUser(parent=account, key_name=hash, 
user=user, account=account)
  145 gooser.put()
  146 return account

  Note that moving the creation of the gooser above the creation of the account 
(and swapping the parent/child relationship between them and making other 
required code changes to temporarily support that) does work.

  Why does this happen?

  Currently my two theories are: A) the detection code is incorrect, and is 
making assumptions about "same model", and B) entities that don't exist yet are 
only considered in the same entity group as that entity itself, so even though 
I'm going to create that entity later into the same entity group, I can't put a 
different object first as the data store can't tell the difference. I am 
guessing that B is correct, in which case maybe someone else working on this 
same problem will find this post and be helped by it. If it isn't B, then maybe 
someone would be kind enough to tell me what the problem actually is ;P.

  -J








--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: using GAE to serve largely static files for an AJAX based application.

[bryan rasmussen]

exactly. it's funny, I never tried to get around the limitation before
but I had supposed it was possible basically because of the
possibility with the iframe workaround. I hadn't expected that it
would need to use the iframe hack to do it!


Cheers,
Bryan Rasmussen

On Wed, Nov 12, 2008 at 6:15 PM, Barry Hunter
<[EMAIL PROTECTED]> wrote:
>
> Not strictly true. Subdomains can talk to each other (or least they
> could, havent used this technique for a while now)
>
> http://fettig.net/weblog/2005/11/28/how-to-make-xmlhttprequest-connections-to-another-server-in-your-domain/
>
>
>
> On Wed, Nov 12, 2008 at 4:54 PM, yejun <[EMAIL PROTECTED]> wrote:
>>
>> XHR require the host name be exactly same. So you have to server your
>> page and xml both off same server.
>>
>> On Nov 12, 4:49 am, "bryan rasmussen" <[EMAIL PROTECTED]>
>> wrote:
>>> As per the subject:
>>>
>>> I have an ajax based application, I figured I could offload some of
>>> the static XML files I need to serve via XHR off to GAE, then when I
>>> am doing a new XHR request check for a file, if that file does not
>>> return 200 I am currently not accessing GAE so switch to some other
>>> service. Does this seem reasonable. Another problem is obviously that
>>> I will need to do some DNS settings to make sure that I can serve my
>>> initial request from my domain and then get further requests via  XHR
>>> from app engine. Has anyone tried a similar setup or have suggestions,
>>> note problems with the approach?
>>>
>>> Thanks,
>>> Bryan Rasmussen
>> >
>>
>
>
>
> --
> Barry
>
> - www.nearby.org.uk - www.geograph.org.uk -
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: import nltk libraries in appengine

[Alexander Kojevnikov]

In addition to what Jeff said, you can use zipimport to reduce the
number of files in your project (there is a 1,000-files limit).

This article explains how to do it by the example of Django 1.0 source
code:
http://code.google.com/appengine/articles/django10_zipimport.html

--
www.muspy.com

On Nov 14, 4:42 am, Jeff S <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> I'm not familiar with NLTK but in general the way to include Python
> libraries in your app is to place the source code in the top level
> directory of your app so that it is uploaded along with your app's
> code. Your app's directory structure might look something like this:
>
> app_name/
>   |- app.yaml
>   |- 
>   |- ntlk
>      |- chat
>      |- chunk
>      |- classify
>      |- ...
>
> If NLTK has other Python libraries which it depends on, those will
> also need to be included in your app. If these libraries are not pure
> Python (contain C code) then you will not be able to use them on App
> Engine.
>
> http://code.google.com/appengine/kb/commontasks.html#thirdparty
>
> Happy coding,
>
> Jeff
>
> On Nov 12, 7:42 am, alexarsh <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > I have appengine project and I would like to use nltk libraries.
> > Can someone give me a step by step instructions how to include nltk
> > libraries to my project in order to be able to do "import nltk" from
> > my appengine project?
>
> > Thanks, Alex Arshavski.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: 有个想法，想写 个工具帮助自动生成AppEngine的项目文件

[cpedia]

If you just want to build a common framework, you can try
Appcelerator.

BTW: try your best to use English in a international forum.


On Nov 13, 6:53 am, A.TNG <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> ϰGAE��д�˼���С���򣬲���Ҳ��һЩ���ܣ�ij�뷨�ҷ���һ�¡�
>
> ��⣺
> �о��GAE�ij���ȷʵ�Ƚϼ򵥣python��ƣҲ�ܿ��ġǣ���Ҫ��ͷ��ʼһ��AppEngine���򣬻�Щ�鷳Ҫһ��app.yaml�Ҫ�Լ�дҪ��סyaml���﷨ʵ�ʱ���Ҷ��Ǵ���ǰ��һĿ�Ҫдһ��main.py��ҪimportһЩclass���Ҷ���Щclass�ر���⣬ÿ��Ҳ�«��ư��ֱ�ӿ���ʵ��һ���ṩ�򵥹��ܵ�ϵͳԭ�͵�ʱ���Ҹ�ϣ��̴ӹ��ܺ���ʼд���ţţ��д�˲�Ȥ�Ĺ��ߣ磬��appengine�ṩshell�Ĺ��ܣ��Լ�appfilebrowser���ṩ���ԴĹ��ܣ�zipme�԰վ��Ĵ�zip�Щ���ܶ��dz��ᣬ�ܶ�ʱ��Ϊ�˷��㣬��ϣЩ���ҵ���Ŀ�ļ档���Dz���ǣ�Ҫ���أߴӱ��ص�ij���ļ��п��ʹ�õ�AppEngineû�д��һЩ��⣬��ʹ��http://groups.google.com/group/google-appengine/web/google-app-engine...
> �ṩ�Ĺ��ʱ��Ҫ�ֶ
> �Ҿ�ã���鷳�ģ��ܶ඼���ظ��Ĺ���
>
> �ܵ
> �ΪҲ�õ�YUI��һ��js��webframework��http://developer.yahoo.com/yui/ͬ��һ��ܿ�Ĺ��ߣ���˼��Ī���YUI
>  Dependency
> Configurator��YUI��˸��ָ"�ؼ�"��ÿ��ؼ���һЩjs��css��ɣǿ��Dz�ÿ�ζ���Ҫʹ�õеĿؼ���һЩ�ؼ�֮�仹���ϵ��YUI
> Dependency 
> Configurator���ṩ��һ��ҳ�棬���û��Լ�ѡҪ�Ŀؼ���Ȼ���һ��HTML���룬ֱ�Ӱ���ҳ�棬�Ϳ���ʹ��YUI�ˡ�
> Ȥ�Ŀ��Կ�http://developer.yahoo.com/yui/articles/hosting/��
> ���룬�ܲ���Ҳ��һ�ƵĹ��ߣܴǣ�ҳ���г��˿�GAE���õ��ĸ�⣬�ûԸ���Լ���ѡ��һЩ��⣬Ȼһ��ť���Ӷ�õ�һ��zipõ�app.yaml,
> main.py��һЩĬ�ϵ��ļ��Լ�Ҫ�Դ���룬��Ȼmain.py�Ѿ˳�ʼ�Ĵ��룬�ʼʵ��ԭ��ϵͳ�ˡ�
>
> �ṩ�ķ��㣺
> 1. ���԰ѧ�ߣ�AppEngine���ż�
> 2. һЩ�о�ˣ���ʡ�ظ��Ͷ���ʱ�䡣
>
> ��ʱ���˸֣Գ�Ϊ gae-util-suit
>
> ��֪��ô�и�õĽߣû���Ҫ��
> ��ӭ�� :)
>
> --
> Best Regards,
> TANG Jiyu
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Copying local datastore

[Alexander Kojevnikov]

> ¿Is it possible to copy the content of my local database to the server
> one? It should be quite usefull in order to preload some data for my
> users

No, but it's on the short-term roadmap:
http://code.google.com/appengine/docs/roadmap.html

You can also use the bulk data uploader:
http://code.google.com/appengine/articles/bulkload.html

--
www.muspy.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: downloading and editing app database

[adrian]

Thanks, your suggestion for #2 will work.

For #1 the link is:

http://code.google.com/p/gawsh/wiki/BulkDownload

But it looks like it is barely tested.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Saving files in Google app engine

[jens]

Hello!

Would it be possible to save files from a web page in the app engine?
If i have a html form and enter som text is it then possible to save
that text to a file on my local drive?

Thanks!

/J

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Jeff S]

Hi Gayle,

Could you email your app id (x.appspot.com) ? I'd be happy to look
into this for you.

Cheers,

Jeff

On Nov 13, 12:43 pm, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> I'm now hitting TONS of "over quota" errors, and I wasn't before.
>
> This is really hurting my revenue today.
>
> http://www.careercup.com
>
> On Nov 13, 11:09 am, "Brett (Google)" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Hi Gee,
>
> > Definitely understood that there's been quite a bit of trouble the
> > last two days, especially for you and a few other apps. We're sorry
> > you guys have been hurting from this. I can imagine it's especially
> > frustrating for a growing service.
>
> > In the specific case of this memcache maintenance, the fail-fast issue
> > lead to high CPU and response time problems for applications that rely
> > heavily on memcache. We're working to resolve this fail-fast issue so
> > it will not happen again. We also came up with an interim solution
> > that will prevent this problem from happening during future memcache
> > maintenances.
>
> > Otherwise, I understand the pain you're feeling here, and relaxing
> > response times and CPU times would be one way to alleviate that. Our
> > team is working hard to improve this in general. Feel free to email
> > Pete, Paul, or me if you have any more questions.
>
> > The good news is that memcache is now back up and serving. Please let
> > us know if you encounter any more issues!
>
> > -Brett
>
> > On Nov 13, 10:50 am, gee <[EMAIL PROTECTED]> wrote:
>
> > > Hi Brett,
>
> > > During this time, it would have been very extremely helpful if CPU/
> > > response time quotas were relaxed.
>
> > > All our cache misses are adding up, and we're now over quota.
>
> > > We've had significant downtime over the last two days due to the
> > > scheduled downtimes going awry (our app was one of those taken down
> > > unexpectedly Tuesday night), and it's definitely hurting our users'
> > > experience with our growing service.  Any help would be much
> > > appreciated.
>
> > > Thanks
> > > Gee
>
> > > On Nov 13, 10:30 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Memcache calls should now be failing fast. That should significantly
> > > > reduce the number of request deadlines people are seeing. Otherwise,
> > > > we're working to bring the memcache API back online for all
> > > > applications as soon as possible. Thanks again for your patience,
> > > > everyone!
>
> > > > On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > Hi Gayle,
>
> > > > > Yes, the *request* times out during the API call. It's not the API
> > > > > call itself that's timing out. But there is no effective difference to
> > > > > your application if you're caught in this situation (as you pointed
> > > > > out). I'd assume the first few calls you make to memcache during a
> > > > > request actually return False and None. But later on in your request
> > > > > handler, so much time has already passed that your API call gets
> > > > > interrupted by the DeadlineExceededException for the entire request.
>
> > > > > I think for now your best bet is to catch the runtime
> > > > > DeadlineExceededException and immediately return with some kind of
> > > > > error code. We're looking into the cause of the delayed memcache calls
> > > > > on failure. They should be immediately failing instead of waiting up
> > > > > to a second to return. That's the root cause of the issue here.
>
> > > > > I'm sorry for the trouble this is causing for your application. We're
> > > > > working right now to address this issue. Someone from the team will
> > > > > follow up when everything has been resolved.
>
> > > > > -Brett
>
> > > > > On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > > > > It was timing out within memcache.get and memcache.set -
> > > > > > consistently.  If I understand you correctly - you're saying that
> > > > > > memcache isn't technically timing out, on the grounds that it would
> > > > > > complete if given enough time.  But, the cache misses take SO much
> > > > > > time that it consistently timeouts during the operations of
> > > > > > memcache.get and memcache.set.
>
> > > > > > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > > > > > difference between that and timing out.  Either way, memcache.get 
> > > > > > and
> > > > > > memcache.set aren't exactly just "return false and letting your
> > > > > > application proceed."  The fact is they are causing timeouts.
>
> > > > > > obj = memcache.get(cache_key)
> > > > > >   File 
> > > > > > "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > > > > > __init__.py", line 362, in get
> > > > > >     self._make_sync_call('memcache', 'Get', request, response)
>
> > > > > >   File "/base/python_lib/versions/1/google/appengine/api/
> > > > > > apiproxy_stub_map.py", line 46, in MakeSyncCall
> > > > > >     stub.MakeSyncCall(service, call, request, response)
> > >

[google-appengine] Re: Memcache API Timing out

[Gayle Laakmann]

I'm now hitting TONS of "over quota" errors, and I wasn't before.

This is really hurting my revenue today.

http://www.careercup.com

On Nov 13, 11:09 am, "Brett (Google)" <[EMAIL PROTECTED]>
wrote:
> Hi Gee,
>
> Definitely understood that there's been quite a bit of trouble the
> last two days, especially for you and a few other apps. We're sorry
> you guys have been hurting from this. I can imagine it's especially
> frustrating for a growing service.
>
> In the specific case of this memcache maintenance, the fail-fast issue
> lead to high CPU and response time problems for applications that rely
> heavily on memcache. We're working to resolve this fail-fast issue so
> it will not happen again. We also came up with an interim solution
> that will prevent this problem from happening during future memcache
> maintenances.
>
> Otherwise, I understand the pain you're feeling here, and relaxing
> response times and CPU times would be one way to alleviate that. Our
> team is working hard to improve this in general. Feel free to email
> Pete, Paul, or me if you have any more questions.
>
> The good news is that memcache is now back up and serving. Please let
> us know if you encounter any more issues!
>
> -Brett
>
> On Nov 13, 10:50 am, gee <[EMAIL PROTECTED]> wrote:
>
> > Hi Brett,
>
> > During this time, it would have been very extremely helpful if CPU/
> > response time quotas were relaxed.
>
> > All our cache misses are adding up, and we're now over quota.
>
> > We've had significant downtime over the last two days due to the
> > scheduled downtimes going awry (our app was one of those taken down
> > unexpectedly Tuesday night), and it's definitely hurting our users'
> > experience with our growing service.  Any help would be much
> > appreciated.
>
> > Thanks
> > Gee
>
> > On Nov 13, 10:30 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Memcache calls should now be failing fast. That should significantly
> > > reduce the number of request deadlines people are seeing. Otherwise,
> > > we're working to bring the memcache API back online for all
> > > applications as soon as possible. Thanks again for your patience,
> > > everyone!
>
> > > On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Hi Gayle,
>
> > > > Yes, the *request* times out during the API call. It's not the API
> > > > call itself that's timing out. But there is no effective difference to
> > > > your application if you're caught in this situation (as you pointed
> > > > out). I'd assume the first few calls you make to memcache during a
> > > > request actually return False and None. But later on in your request
> > > > handler, so much time has already passed that your API call gets
> > > > interrupted by the DeadlineExceededException for the entire request.
>
> > > > I think for now your best bet is to catch the runtime
> > > > DeadlineExceededException and immediately return with some kind of
> > > > error code. We're looking into the cause of the delayed memcache calls
> > > > on failure. They should be immediately failing instead of waiting up
> > > > to a second to return. That's the root cause of the issue here.
>
> > > > I'm sorry for the trouble this is causing for your application. We're
> > > > working right now to address this issue. Someone from the team will
> > > > follow up when everything has been resolved.
>
> > > > -Brett
>
> > > > On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > > > It was timing out within memcache.get and memcache.set -
> > > > > consistently.  If I understand you correctly - you're saying that
> > > > > memcache isn't technically timing out, on the grounds that it would
> > > > > complete if given enough time.  But, the cache misses take SO much
> > > > > time that it consistently timeouts during the operations of
> > > > > memcache.get and memcache.set.
>
> > > > > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > > > > difference between that and timing out.  Either way, memcache.get and
> > > > > memcache.set aren't exactly just "return false and letting your
> > > > > application proceed."  The fact is they are causing timeouts.
>
> > > > > obj = memcache.get(cache_key)
> > > > >   File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > > > > __init__.py", line 362, in get
> > > > >     self._make_sync_call('memcache', 'Get', request, response)
>
> > > > >   File "/base/python_lib/versions/1/google/appengine/api/
> > > > > apiproxy_stub_map.py", line 46, in MakeSyncCall
> > > > >     stub.MakeSyncCall(service, call, request, response)
> > > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > > apiproxy.py", line 245, in MakeSyncCall
>
> > > > >     rpc.Wait()
> > > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > > apiproxy.py", line 161, in Wait
> > > > >     rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
>
> > > > > On Nov 13, 9:45 am,

[google-appengine] Quota and static files

[Sylvain]

Hi,

Since static files are not counted in the Dashboard (http://
code.google.com/p/googleappengine/issues/detail?id=521)

I'd like to know if there are quotas for this kind of files ? If yes,
is this similar to this : http://code.google.com/appengine/articles/quotas.html

Thank you

Regards
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] New behaviour in the fetch method?

[plunchete]

AFAIk since a couple of weeks an operation like model.Foo.all().fetch
(limit, offset) with an offset greater than 1000 launched an
exception, but yesterday I was testing the operation and it works!.

IMHO this is the correct behaviour, but I would like an official
confirmation just in case :)

Cheers,

Ignacio

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: n00b problem: can't print member values

[Faber Fedor]

On Thu, Nov 13, 2008 at 1:51 PM, Marzia Niccolai <[EMAIL PROTECTED]> wrote:

> Ah, so I thought you were trying to access the object key.


Which was a perfectly reasonable thing for you to think.


> In this case, does your model definition have the ()?
>
> So,
>
> class ProgressEvent(db.Model):
>   senderId = db.StringProperty()


DOH!  That was it!  Told ya' it was a n00b mistake! :-)

Thanks!

--

faber

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Brett (Google)]

Hi Gee,

Definitely understood that there's been quite a bit of trouble the
last two days, especially for you and a few other apps. We're sorry
you guys have been hurting from this. I can imagine it's especially
frustrating for a growing service.

In the specific case of this memcache maintenance, the fail-fast issue
lead to high CPU and response time problems for applications that rely
heavily on memcache. We're working to resolve this fail-fast issue so
it will not happen again. We also came up with an interim solution
that will prevent this problem from happening during future memcache
maintenances.

Otherwise, I understand the pain you're feeling here, and relaxing
response times and CPU times would be one way to alleviate that. Our
team is working hard to improve this in general. Feel free to email
Pete, Paul, or me if you have any more questions.

The good news is that memcache is now back up and serving. Please let
us know if you encounter any more issues!

-Brett


On Nov 13, 10:50 am, gee <[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> During this time, it would have been very extremely helpful if CPU/
> response time quotas were relaxed.
>
> All our cache misses are adding up, and we're now over quota.
>
> We've had significant downtime over the last two days due to the
> scheduled downtimes going awry (our app was one of those taken down
> unexpectedly Tuesday night), and it's definitely hurting our users'
> experience with our growing service.  Any help would be much
> appreciated.
>
> Thanks
> Gee
>
> On Nov 13, 10:30 am, "Brett (Google)" <[EMAIL PROTECTED]>
> wrote:
>
> > Memcache calls should now be failing fast. That should significantly
> > reduce the number of request deadlines people are seeing. Otherwise,
> > we're working to bring the memcache API back online for all
> > applications as soon as possible. Thanks again for your patience,
> > everyone!
>
> > On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi Gayle,
>
> > > Yes, the *request* times out during the API call. It's not the API
> > > call itself that's timing out. But there is no effective difference to
> > > your application if you're caught in this situation (as you pointed
> > > out). I'd assume the first few calls you make to memcache during a
> > > request actually return False and None. But later on in your request
> > > handler, so much time has already passed that your API call gets
> > > interrupted by the DeadlineExceededException for the entire request.
>
> > > I think for now your best bet is to catch the runtime
> > > DeadlineExceededException and immediately return with some kind of
> > > error code. We're looking into the cause of the delayed memcache calls
> > > on failure. They should be immediately failing instead of waiting up
> > > to a second to return. That's the root cause of the issue here.
>
> > > I'm sorry for the trouble this is causing for your application. We're
> > > working right now to address this issue. Someone from the team will
> > > follow up when everything has been resolved.
>
> > > -Brett
>
> > > On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > > It was timing out within memcache.get and memcache.set -
> > > > consistently.  If I understand you correctly - you're saying that
> > > > memcache isn't technically timing out, on the grounds that it would
> > > > complete if given enough time.  But, the cache misses take SO much
> > > > time that it consistently timeouts during the operations of
> > > > memcache.get and memcache.set.
>
> > > > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > > > difference between that and timing out.  Either way, memcache.get and
> > > > memcache.set aren't exactly just "return false and letting your
> > > > application proceed."  The fact is they are causing timeouts.
>
> > > > obj = memcache.get(cache_key)
> > > >   File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > > > __init__.py", line 362, in get
> > > >     self._make_sync_call('memcache', 'Get', request, response)
>
> > > >   File "/base/python_lib/versions/1/google/appengine/api/
> > > > apiproxy_stub_map.py", line 46, in MakeSyncCall
> > > >     stub.MakeSyncCall(service, call, request, response)
> > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > apiproxy.py", line 245, in MakeSyncCall
>
> > > >     rpc.Wait()
> > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > apiproxy.py", line 161, in Wait
> > > >     rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
>
> > > > On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
>
> > > > > Hi Gayle,
>
> > > > > I'm sorry to hear you're seeing issues. It's important to note that
> > > > > there are two types of DeadlineExceededErrors. One is defined in
> > > > > apiproxy_errors.py. The other is in runtime/__init__.py:
>
> > > > >http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
>
> > >

[google-appengine] Re: ReferenceProperty could avoid unnecesary resolve

[Bill]

I've added the solution to the Cookbook and the FAQ:
http://appengine-cookbook.appspot.com/recipe/getting-dbreferenceproperty-key-without-loading-entity

On a previous thread, someone came up with a metaclass solution as
well.
-Bill

On Nov 13, 10:01 am, "Chris Marasti-Georg" <[EMAIL PROTECTED]>
wrote:
> Wooble, that's incorrect.  The solution is 
> here:http://stackoverflow.com/questions/141973/how-do-i-get-the-key-value-...
>
> On Thu, Nov 13, 2008 at 11:04 AM, Wooble <[EMAIL PROTECTED]> wrote:
>
> > How would that be more efficient?  The entity isn't fetched until you
> > try to use it as an instance anyway.
>
> > On Nov 13, 10:42 am, tigrillo <[EMAIL PROTECTED]>
> > wrote:
> > > For the sake of efficient, it will be nice if ReferenceProperty let's
> > > us return the Key optionally instead of the Entity.
>
> > > Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Setting timeout for urlfetch requests

[Marzia Niccolai]

Hi Rob,

Currently, App Engine doesn't support user defined timeouts on URLFetch, but
if you are interested in this, you should start the issue in the tracker:
http://code.google.com/p/googleappengine/issues/detail?id=79

-Marzia

On Wed, Nov 12, 2008 at 7:01 PM, robfig <[EMAIL PROTECTED]> wrote:

>
> Hello!
> Part of the service I'm developing involves scraping some data via a
> POST (until the data provider gets an API together).  However, it
> takes longer than 5 seconds, so I constantly see: "DownloadError:
> ApplicationError: 5" when running from appspot.  Is there any way
> around this?
> Thanks,
> Rob
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Marzia Niccolai]

Hi Gee,

Can you please reply to me with your app ID and I can look in to it.

-Marzia

On Thu, Nov 13, 2008 at 10:50 AM, gee <[EMAIL PROTECTED]> wrote:

>
>
> Hi Brett,
>
> During this time, it would have been very extremely helpful if CPU/
> response time quotas were relaxed.
>
> All our cache misses are adding up, and we're now over quota.
>
> We've had significant downtime over the last two days due to the
> scheduled downtimes going awry (our app was one of those taken down
> unexpectedly Tuesday night), and it's definitely hurting our users'
> experience with our growing service.  Any help would be much
> appreciated.
>
> Thanks
> Gee
>
>
>
>
>
>
> On Nov 13, 10:30 am, "Brett (Google)" <[EMAIL PROTECTED]>
> wrote:
> > Memcache calls should now be failing fast. That should significantly
> > reduce the number of request deadlines people are seeing. Otherwise,
> > we're working to bring the memcache API back online for all
> > applications as soon as possible. Thanks again for your patience,
> > everyone!
> >
> > On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi Gayle,
> >
> > > Yes, the *request* times out during the API call. It's not the API
> > > call itself that's timing out. But there is no effective difference to
> > > your application if you're caught in this situation (as you pointed
> > > out). I'd assume the first few calls you make to memcache during a
> > > request actually return False and None. But later on in your request
> > > handler, so much time has already passed that your API call gets
> > > interrupted by the DeadlineExceededException for the entire request.
> >
> > > I think for now your best bet is to catch the runtime
> > > DeadlineExceededException and immediately return with some kind of
> > > error code. We're looking into the cause of the delayed memcache calls
> > > on failure. They should be immediately failing instead of waiting up
> > > to a second to return. That's the root cause of the issue here.
> >
> > > I'm sorry for the trouble this is causing for your application. We're
> > > working right now to address this issue. Someone from the team will
> > > follow up when everything has been resolved.
> >
> > > -Brett
> >
> > > On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> >
> > > > It was timing out within memcache.get and memcache.set -
> > > > consistently.  If I understand you correctly - you're saying that
> > > > memcache isn't technically timing out, on the grounds that it would
> > > > complete if given enough time.  But, the cache misses take SO much
> > > > time that it consistently timeouts during the operations of
> > > > memcache.get and memcache.set.
> >
> > > > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > > > difference between that and timing out.  Either way, memcache.get and
> > > > memcache.set aren't exactly just "return false and letting your
> > > > application proceed."  The fact is they are causing timeouts.
> >
> > > > obj = memcache.get(cache_key)
> > > >   File
> "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > > > __init__.py", line 362, in get
> > > > self._make_sync_call('memcache', 'Get', request, response)
> >
> > > >   File "/base/python_lib/versions/1/google/appengine/api/
> > > > apiproxy_stub_map.py", line 46, in MakeSyncCall
> > > > stub.MakeSyncCall(service, call, request, response)
> > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > apiproxy.py", line 245, in MakeSyncCall
> >
> > > > rpc.Wait()
> > > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > > apiproxy.py", line 161, in Wait
> > > > rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
> >
> > > > On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
> >
> > > > > Hi Gayle,
> >
> > > > > I'm sorry to hear you're seeing issues. It's important to note that
> > > > > there are two types of DeadlineExceededErrors. One is defined in
> > > > > apiproxy_errors.py. The other is in runtime/__init__.py:
> >
> > > > >
> http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
> >
> > > > > The names are the same, which makes this confusing. The latter
> error
> > > > > is raised when the request has been processing for too long (~10
> > > > > seconds). Perhaps what's happening here is that the cache misses
> are
> > > > > causing a lot of extra work to be done, causing your application to
> > > > > hit this other deadline.
> >
> > > > > The traceback sent by Pratham confirms this behavior. More detail
> on
> > > > > how to deal with this is here, in the section entitled "The Request
> > > > > Timer":
> >
> > > > >http://code.google.com/appengine/docs/python/requestsandcgi.html
> >
> > > > > -Brett
> >
> > > > > On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> >
> > > > > > Despite what the post at the link below says, memcache is
> actually
> > > > > > timing out and throwing a DeadlineExce

[google-appengine] Re: n00b problem: can't print member values

[Marzia Niccolai]

Ah, so I thought you were trying to access the object key.

In this case, does your model definition have the ()?

So,

class ProgressEvent(db.Model):
  senderId = db.StringProperty()

?

On Thu, Nov 13, 2008 at 10:45 AM, Faber Fedor <[EMAIL PROTECTED]> wrote:

> On Thu, Nov 13, 2008 at 1:33 PM, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> It should be:
>>
>> self.response.out.write(pevent.key())
>
>
> That didn't work either. :-?
>
> Bad choice of member name on my part.  Let me rephrase the code:
>
>for pevent in pevents: # I've also used "for pevent in query:"
>self.response.out.write(pevent.senderId)
>self.response.out.write("\n")
>
> where senderId is a member of the object.
>
> On a whim, I did
>
>self.response.out.write(pevent.senderId())
>
> which, to my mind, should have generated an error, but didn't.  The code
> still printed out
> Showing events:
> 
> 
>
>
> Sometimes these kinds of things are hard to see in your own code :)
>
>
> I know.  The strange thing is I have this working in *another* project.  I
> can't tell the difference between the two (other than the objects in
> question).
>
>
>>
>>
>> -Marzia
>>
>>
>> On Thu, Nov 13, 2008 at 9:41 AM, faber <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I think I'm missing something really simple here but I can't see
>>> what.  I have an object I'm calling ProgressEvent (PE) which is a
>>> db.Model that I've successfully written and stored.  I am now writing
>>> a function to show all the PEs in the datastore, so I wrote this:
>>>
>>> class showProgressEvents(webapp.RequestHandler):
>>>def get(self):
>>>query = ProgressEvent.all()
>>>pevents = query.fetch(10)
>>>
>>>self.response.out.write("Showing events:\n")
>>>
>>>for pevent in pevents: # I've also used "for pevent in query:"
>>>self.response.out.write(pevent.key)
>>>self.response.out.write("\n")
>>>
>>> But all it ever prints is:
>>> Showing events:
>>> 
>>> 
>>>
>>> The number of lines printed is correct. What am I missing?
>>>
>>> --
>>>
>>> faber
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[gee]

Hi Brett,

During this time, it would have been very extremely helpful if CPU/
response time quotas were relaxed.

All our cache misses are adding up, and we're now over quota.

We've had significant downtime over the last two days due to the
scheduled downtimes going awry (our app was one of those taken down
unexpectedly Tuesday night), and it's definitely hurting our users'
experience with our growing service.  Any help would be much
appreciated.

Thanks
Gee






On Nov 13, 10:30 am, "Brett (Google)" <[EMAIL PROTECTED]>
wrote:
> Memcache calls should now be failing fast. That should significantly
> reduce the number of request deadlines people are seeing. Otherwise,
> we're working to bring the memcache API back online for all
> applications as soon as possible. Thanks again for your patience,
> everyone!
>
> On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Gayle,
>
> > Yes, the *request* times out during the API call. It's not the API
> > call itself that's timing out. But there is no effective difference to
> > your application if you're caught in this situation (as you pointed
> > out). I'd assume the first few calls you make to memcache during a
> > request actually return False and None. But later on in your request
> > handler, so much time has already passed that your API call gets
> > interrupted by the DeadlineExceededException for the entire request.
>
> > I think for now your best bet is to catch the runtime
> > DeadlineExceededException and immediately return with some kind of
> > error code. We're looking into the cause of the delayed memcache calls
> > on failure. They should be immediately failing instead of waiting up
> > to a second to return. That's the root cause of the issue here.
>
> > I'm sorry for the trouble this is causing for your application. We're
> > working right now to address this issue. Someone from the team will
> > follow up when everything has been resolved.
>
> > -Brett
>
> > On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > It was timing out within memcache.get and memcache.set -
> > > consistently.  If I understand you correctly - you're saying that
> > > memcache isn't technically timing out, on the grounds that it would
> > > complete if given enough time.  But, the cache misses take SO much
> > > time that it consistently timeouts during the operations of
> > > memcache.get and memcache.set.
>
> > > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > > difference between that and timing out.  Either way, memcache.get and
> > > memcache.set aren't exactly just "return false and letting your
> > > application proceed."  The fact is they are causing timeouts.
>
> > > obj = memcache.get(cache_key)
> > >   File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > > __init__.py", line 362, in get
> > >     self._make_sync_call('memcache', 'Get', request, response)
>
> > >   File "/base/python_lib/versions/1/google/appengine/api/
> > > apiproxy_stub_map.py", line 46, in MakeSyncCall
> > >     stub.MakeSyncCall(service, call, request, response)
> > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > apiproxy.py", line 245, in MakeSyncCall
>
> > >     rpc.Wait()
> > >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > > apiproxy.py", line 161, in Wait
> > >     rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
>
> > > On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
>
> > > > Hi Gayle,
>
> > > > I'm sorry to hear you're seeing issues. It's important to note that
> > > > there are two types of DeadlineExceededErrors. One is defined in
> > > > apiproxy_errors.py. The other is in runtime/__init__.py:
>
> > > >http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
>
> > > > The names are the same, which makes this confusing. The latter error
> > > > is raised when the request has been processing for too long (~10
> > > > seconds). Perhaps what's happening here is that the cache misses are
> > > > causing a lot of extra work to be done, causing your application to
> > > > hit this other deadline.
>
> > > > The traceback sent by Pratham confirms this behavior. More detail on
> > > > how to deal with this is here, in the section entitled "The Request
> > > > Timer":
>
> > > >http://code.google.com/appengine/docs/python/requestsandcgi.html
>
> > > > -Brett
>
> > > > On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > > > Despite what the post at the link below says, memcache is actually
> > > > > timing out and throwing a DeadlineExceededError.  Furthermore, it
> > > > > hardly seems accurate to say that our apps should continue serving
> > > > > normally.  The quota limits are so ridiculously low that we CAN'T
> > > > > serve pages without caching.
>
> > > > >http://groups.google.com/group/google-appengine-downtime-notify/brows...
> > > > > We will be taking memcache offline tomorrow morning from 9-10am PST
>

[google-appengine] Re: n00b problem: can't print member values

[Faber Fedor]

On Thu, Nov 13, 2008 at 1:33 PM, Marzia Niccolai <[EMAIL PROTECTED]> wrote:

> Hi,
>
> It should be:
>
> self.response.out.write(pevent.key())


That didn't work either. :-?

Bad choice of member name on my part.  Let me rephrase the code:

   for pevent in pevents: # I've also used "for pevent in query:"
   self.response.out.write(pevent.senderId)
   self.response.out.write("\n")

where senderId is a member of the object.

On a whim, I did

   self.response.out.write(pevent.senderId())

which, to my mind, should have generated an error, but didn't.  The code
still printed out
Showing events:




Sometimes these kinds of things are hard to see in your own code :)


I know.  The strange thing is I have this working in *another* project.  I
can't tell the difference between the two (other than the objects in
question).


>
>
> -Marzia
>
>
> On Thu, Nov 13, 2008 at 9:41 AM, faber <[EMAIL PROTECTED]> wrote:
>
>>
>> I think I'm missing something really simple here but I can't see
>> what.  I have an object I'm calling ProgressEvent (PE) which is a
>> db.Model that I've successfully written and stored.  I am now writing
>> a function to show all the PEs in the datastore, so I wrote this:
>>
>> class showProgressEvents(webapp.RequestHandler):
>>def get(self):
>>query = ProgressEvent.all()
>>pevents = query.fetch(10)
>>
>>self.response.out.write("Showing events:\n")
>>
>>for pevent in pevents: # I've also used "for pevent in query:"
>>self.response.out.write(pevent.key)
>>self.response.out.write("\n")
>>
>> But all it ever prints is:
>> Showing events:
>> 
>> 
>>
>> The number of lines printed is correct. What am I missing?
>>
>> --
>>
>> faber
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: n00b problem: can't print member values

[Marzia Niccolai]

Hi,

It should be:

self.response.out.write(pevent.key())

Sometimes these kinds of things are hard to see in your own code :)

-Marzia

On Thu, Nov 13, 2008 at 9:41 AM, faber <[EMAIL PROTECTED]> wrote:

>
> I think I'm missing something really simple here but I can't see
> what.  I have an object I'm calling ProgressEvent (PE) which is a
> db.Model that I've successfully written and stored.  I am now writing
> a function to show all the PEs in the datastore, so I wrote this:
>
> class showProgressEvents(webapp.RequestHandler):
>def get(self):
>query = ProgressEvent.all()
>pevents = query.fetch(10)
>
>self.response.out.write("Showing events:\n")
>
>for pevent in pevents: # I've also used "for pevent in query:"
>self.response.out.write(pevent.key)
>self.response.out.write("\n")
>
> But all it ever prints is:
> Showing events:
> 
> 
>
> The number of lines printed is correct. What am I missing?
>
> --
>
> faber
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Brett (Google)]

Memcache calls should now be failing fast. That should significantly
reduce the number of request deadlines people are seeing. Otherwise,
we're working to bring the memcache API back online for all
applications as soon as possible. Thanks again for your patience,
everyone!

On Nov 13, 10:12 am, "Brett (Google)" <[EMAIL PROTECTED]>
wrote:
> Hi Gayle,
>
> Yes, the *request* times out during the API call. It's not the API
> call itself that's timing out. But there is no effective difference to
> your application if you're caught in this situation (as you pointed
> out). I'd assume the first few calls you make to memcache during a
> request actually return False and None. But later on in your request
> handler, so much time has already passed that your API call gets
> interrupted by the DeadlineExceededException for the entire request.
>
> I think for now your best bet is to catch the runtime
> DeadlineExceededException and immediately return with some kind of
> error code. We're looking into the cause of the delayed memcache calls
> on failure. They should be immediately failing instead of waiting up
> to a second to return. That's the root cause of the issue here.
>
> I'm sorry for the trouble this is causing for your application. We're
> working right now to address this issue. Someone from the team will
> follow up when everything has been resolved.
>
> -Brett
>
> On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > It was timing out within memcache.get and memcache.set -
> > consistently.  If I understand you correctly - you're saying that
> > memcache isn't technically timing out, on the grounds that it would
> > complete if given enough time.  But, the cache misses take SO much
> > time that it consistently timeouts during the operations of
> > memcache.get and memcache.set.
>
> > Ok, sure, that may be the case.  I'm afraid I don't really see the
> > difference between that and timing out.  Either way, memcache.get and
> > memcache.set aren't exactly just "return false and letting your
> > application proceed."  The fact is they are causing timeouts.
>
> > obj = memcache.get(cache_key)
> >   File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> > __init__.py", line 362, in get
> >     self._make_sync_call('memcache', 'Get', request, response)
>
> >   File "/base/python_lib/versions/1/google/appengine/api/
> > apiproxy_stub_map.py", line 46, in MakeSyncCall
> >     stub.MakeSyncCall(service, call, request, response)
> >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > apiproxy.py", line 245, in MakeSyncCall
>
> >     rpc.Wait()
> >   File "/base/python_lib/versions/1/google/appengine/runtime/
> > apiproxy.py", line 161, in Wait
> >     rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
>
> > On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
>
> > > Hi Gayle,
>
> > > I'm sorry to hear you're seeing issues. It's important to note that
> > > there are two types of DeadlineExceededErrors. One is defined in
> > > apiproxy_errors.py. The other is in runtime/__init__.py:
>
> > >http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
>
> > > The names are the same, which makes this confusing. The latter error
> > > is raised when the request has been processing for too long (~10
> > > seconds). Perhaps what's happening here is that the cache misses are
> > > causing a lot of extra work to be done, causing your application to
> > > hit this other deadline.
>
> > > The traceback sent by Pratham confirms this behavior. More detail on
> > > how to deal with this is here, in the section entitled "The Request
> > > Timer":
>
> > >http://code.google.com/appengine/docs/python/requestsandcgi.html
>
> > > -Brett
>
> > > On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > > Despite what the post at the link below says, memcache is actually
> > > > timing out and throwing a DeadlineExceededError.  Furthermore, it
> > > > hardly seems accurate to say that our apps should continue serving
> > > > normally.  The quota limits are so ridiculously low that we CAN'T
> > > > serve pages without caching.
>
> > > >http://groups.google.com/group/google-appengine-downtime-notify/brows...
> > > > We will be taking memcache offline tomorrow morning from 9-10am PST
> > > > (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> > > > throw exceptions but will instead return false for set() calls and
> > > > None for get() calls (just like any other cache miss.)
>
> > > > Your app should continue serving normally during this period, and
> > > > we'll keep you updated on our progress. "
>
> > > > Additonally, I'd like to make two suggestions:
> > > > 1. If you're going to take down memcache, wouldn't it make sense to
> > > > remove the quota limits?  It hardly seems fair to penalized for
> > > > exceeding quota when caching is disabled.
>
> > > > 2.  If you have to take down our apps for an hour, can you pick
> > > > somet

[google-appengine] Re: Version number looks weird after my recent upload.

[Marzia Niccolai]

Hi,

The version numbers have been switched so that they are timestamped based,
indicating the time that the version was uploaded.

-Marzia

On Wed, Nov 12, 2008 at 6:28 PM, CNBorn <[EMAIL PROTECTED]> wrote:

>
> Hi All,
>
>I am running a Todolist app on AppEngine(Currently in zh_CN),
> [http://checknerds.appspot.com]. But after a recent upload, I found
> the version number lookss weird. Now the version number hsould be
> 1.89, but I get 1.329236891998284311 instead. Is there something wrong
> with this? Does anybody else encountering the same problem? P.S, It
> seems that the other stuff are running well.
>
> BR,
> CNBorn
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: weird/interesting "multiple entity groups" case

[Charles Srisuwananukorn]

I was seeing this in my app too. The get_by_key_name on line 134 is actually
getting a different GoogleUser than the one put in on line 144.

The full key of an entity includes the key names for each of its ancestors
back to some root entity, meaning two entities of the same kind can have the
same key name if they have different parents. From the docs:

The keys of two different entities can have similar parts as long as at
least one part is different. For instance, two entities can have the same
kind and name if they have different parents. (
http://code.google.com/appengine/docs/datastore/keysandentitygroups.html)

So the get_by_key_name below is fetching a GoogleUser whose key name matches
the value of "hash" and has no parents. To get the right GoogleUser, you'd
need to use

GoogleUser.get(Key.from_path('Account', ,
'GoogleUser', hash))

where you specify either the ID or the key name of the account as well.

Hope that helps.

--Charles

On Thu, Nov 13, 2008 at 3:21 AM, Jay Freeman (saurik) <[EMAIL PROTECTED]>wrote:

>  I am  running into a confusing "can't operate on multiple entity groups
> in a single transaction" case when I am, in fact, not accessing "multiple
> entity groups". I think I understand what might be going on, but A) am not
> certain and B) others might find it interesting, anyway.
>
> What is happening is that I have a transaction that is operating over two
> models: GoogleUser and Account. I get the GoogleUser instance associated
> with the current e-mail address with get_by_key_name and then return
> gooser.account. If I fail to find that GoogleUser, I add a new Account, and
> into the /same entity group/ I add the GoogleUser in question.
>
> For reference, here is the actual code of my transaction:
>
> 132 @staticmethod
> 133 def goi_account_by_primary_key_(user, hash, **kw):
> 134 gooser = GoogleUser.get_by_key_name(hash)
> 135 if gooser:
> 136 account = db.get(gooser.account)
> 137 keys = kw.keys()
> 138 for key in keys:
> 139 setattr(account, key, kw[key])
> 140 account.put()
> 141 else:
> 142 account = Account(**kw)
> 143 account.put()
> 144 gooser = GoogleUser(parent=account, key_name=hash,
> user=user, account=account)
> 145 gooser.put()
> 146 return account
> Note that moving the creation of the gooser above the creation of the
> account (and swapping the parent/child relationship between them and making
> other required code changes to temporarily support that) does work.
>
> Why does this happen?
>
> Currently my two theories are: A) the detection code is incorrect, and is
> making assumptions about "same model", and B) entities that don't exist
> yet are only considered in the same entity group as that entity itself, so
> even though I'm going to create that entity later into the same entity
> group, I can't put a different object first as the data store can't tell the
> difference. I am guessing that B is correct, in which case maybe someone
> else working on this same problem will find this post and be helped by it.
> If it isn't B, then maybe someone would be kind enough to tell me what the
> problem actually is ;P.
>
> -J
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Reminder: Scheduled Maintenance This Evening

[Marzia Niccolai]

Hi,

This is related to the Memcache maintenance, please see the discussion on
this thread:

http://groups.google.com/group/google-appengine/browse_thread/thread/736a51417ede40b4

-Marzia

On Thu, Nov 13, 2008 at 9:25 AM, Scott Mahr <[EMAIL PROTECTED]> wrote:

>
> My app worked yesterday, and now is down as well.   id=o24u
> If I roll back to before I used memcache would it fix it?  Any idea on
> when this will be ironed out?
>
> sample log entry
> 11-13 09:19AM 20.397 / 500 9068ms 4122mcycles 0kb
> 66.215.95.164 - - [13/11/2008:09:19:29 -0800] "GET / HTTP/1.1" 500 0 -
> -
> E 11-13 09:19AM 29.461
> Traceback (most recent call last):
> E 11-13 09:19AM 29.461
>   File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line 92,
> in run
> E 11-13 09:19AM 29.461
> :
> Traceback (most recent call last):
>   File "/base/data/home/apps/o24u/3.7/o24umain.py", line 804, in
> 
>main()
>  File "/base/data/home/apps/o24u/3.7/o24umain.py", line 802, in main
>wsgiref.handlers.CGIHandler().run(application)
>  File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line 96,
> in run
>self.handle_error()
>   File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line
> 306, in handle_error
>self.log_exception(sys.exc_info())
>   File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line
> 298, in log_exception
>self.traceback_limit, stderr
>  File "/base/python_dist/lib/python2.5/traceback.py", line 125, in
> print_exception
>print_tb(tb, limit, file)
>  File "/base/python_dist/lib/python2.5/traceback.py", line 70, in
> print_tb
>if line: _print(file, '' + line.strip())
>
> On Nov 12, 11:58 am, heidmotron <[EMAIL PROTECTED]> wrote:
> > When I try to memcache django's QueryPaginator object I'm getting:
> >
> > PicklingError: Can't pickle : it's not found as
> > __builtin__.instancemethod
> >
> > It was working before yesterday. Is there something new I should be
> > doing?
> >
> > On Nov 11, 11:30 pm, Arun Shanker Prasad <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi,
> >
> > >   Still getting the same error even with setting the value in a list.
> >
> > > Thanks,
> > > Arun Shanker Prasad.
> >
> > > On Nov 12, 11:22 am, Arun Shanker Prasad <[EMAIL PROTECTED]>
> > > wrote:
> >
> > > > Hi,
> >
> > > >  Regarding you option to set the value as a list this is not causing
> > > > any issue and got it working by changing the code. Was this modified
> > > > during the current modification? Because I can still get the same
> code
> > > > to work in the SDK..
> >
> > > > Thanks,
> > > > Arun Shanker Prasad.
> >
> > > > On Nov 12, 10:32 am, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
> >
> > > > > It seems like this error is most likely caused as the result of
> pickling a
> > > > > Query object instead of the results of a query.  Are engineering
> team is
> > > > > looking in to this issue.
> >
> > > > > -Marzia
> >
> > > > > On Tue, Nov 11, 2008 at 9:20 PM, Arun Shanker Prasad <
> >
> > > > > [EMAIL PROTECTED]> wrote:
> >
> > > > > > Hi,
> >
> > > > > >  My app id is space1. I am putting the parentModel.child_set list
> > > > > > into memcahce.
> >
> > > > > > Thanks,
> > > > > > Arun Shanker Prasad.
> >
> > > > > > On Nov 12, 10:16 am, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
> > > > > > > Also, what are you placing in Memcache when your application is
> showing
> > > > > > this
> > > > > > > error?
> >
> > > > > > > -Marzia
> >
> > > > > > > On Tue, Nov 11, 2008 at 9:15 PM, Marzia Niccolai <
> [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > > Hi,
> >
> > > > > > > > What is the app id that is experiencing this issue?
> >
> > > > > > > > -Marzia
> >
> > > > > > > > On Tue, Nov 11, 2008 at 9:13 PM, Arun Shanker Prasad <
> > > > > > > > [EMAIL PROTECTED]> wrote:
> >
> > > > > > > >> Hi,
> > > > > > > >>   Also the error I got was "PicklingError" during the
> memcache
> > > > > > > >> set. This was working last night
> > > > > > > >> Thanks,
> > > > > > > >> Arun Shanker Prasad.
> >
> > > > > > > >> On Nov 12, 9:54 am, Marzia Niccolai <[EMAIL PROTECTED]>
> wrote:
> > > > > > > >> > Hi,
> >
> > > > > > > >> > Another issue occurred during scheduled maintenance
> tonight, which
> > > > > > is
> > > > > > > >> not
> > > > > > > >> > related to the issue mentioned above.
> >
> > > > > > > >> > This issue affected objects stored in Memcache.  If your
> application
> > > > > > was
> > > > > > > >> > affected by this error, you would not have been
> individually
> > > > > > emailed.
> >
> > > > > > > >> > If your application is currently experiencing issues, it
> is most
> > > > > > likely
> > > > > > > >> > related to the Memcache issue which our engineering team
> is
> > > > > > currently
> > > > > > > >> > investigating.  You should see an AttributeError in your
> > > > > > application's
> > > > > > > >> logs.
> >
> > > > > > > >> > We expect this issue will be fixed shortly.
> >
> > > > > > > >> > -Marzia
> >
> > > > > > > >> > On Tue, Nov 11, 2008 at 8:24 PM, Gayle Laak

[google-appengine] Re: Memcache API Timing out

[Brett (Google)]

Hi Gayle,

Yes, the *request* times out during the API call. It's not the API
call itself that's timing out. But there is no effective difference to
your application if you're caught in this situation (as you pointed
out). I'd assume the first few calls you make to memcache during a
request actually return False and None. But later on in your request
handler, so much time has already passed that your API call gets
interrupted by the DeadlineExceededException for the entire request.

I think for now your best bet is to catch the runtime
DeadlineExceededException and immediately return with some kind of
error code. We're looking into the cause of the delayed memcache calls
on failure. They should be immediately failing instead of waiting up
to a second to return. That's the root cause of the issue here.

I'm sorry for the trouble this is causing for your application. We're
working right now to address this issue. Someone from the team will
follow up when everything has been resolved.

-Brett

On Nov 13, 9:57 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> It was timing out within memcache.get and memcache.set -
> consistently.  If I understand you correctly - you're saying that
> memcache isn't technically timing out, on the grounds that it would
> complete if given enough time.  But, the cache misses take SO much
> time that it consistently timeouts during the operations of
> memcache.get and memcache.set.
>
> Ok, sure, that may be the case.  I'm afraid I don't really see the
> difference between that and timing out.  Either way, memcache.get and
> memcache.set aren't exactly just "return false and letting your
> application proceed."  The fact is they are causing timeouts.
>
> obj = memcache.get(cache_key)
>   File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
> __init__.py", line 362, in get
>     self._make_sync_call('memcache', 'Get', request, response)
>
>   File "/base/python_lib/versions/1/google/appengine/api/
> apiproxy_stub_map.py", line 46, in MakeSyncCall
>     stub.MakeSyncCall(service, call, request, response)
>   File "/base/python_lib/versions/1/google/appengine/runtime/
> apiproxy.py", line 245, in MakeSyncCall
>
>     rpc.Wait()
>   File "/base/python_lib/versions/1/google/appengine/runtime/
> apiproxy.py", line 161, in Wait
>     rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)
>
> On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
>
> > Hi Gayle,
>
> > I'm sorry to hear you're seeing issues. It's important to note that
> > there are two types of DeadlineExceededErrors. One is defined in
> > apiproxy_errors.py. The other is in runtime/__init__.py:
>
> >http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
>
> > The names are the same, which makes this confusing. The latter error
> > is raised when the request has been processing for too long (~10
> > seconds). Perhaps what's happening here is that the cache misses are
> > causing a lot of extra work to be done, causing your application to
> > hit this other deadline.
>
> > The traceback sent by Pratham confirms this behavior. More detail on
> > how to deal with this is here, in the section entitled "The Request
> > Timer":
>
> >http://code.google.com/appengine/docs/python/requestsandcgi.html
>
> > -Brett
>
> > On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > > Despite what the post at the link below says, memcache is actually
> > > timing out and throwing a DeadlineExceededError.  Furthermore, it
> > > hardly seems accurate to say that our apps should continue serving
> > > normally.  The quota limits are so ridiculously low that we CAN'T
> > > serve pages without caching.
>
> > >http://groups.google.com/group/google-appengine-downtime-notify/brows...
> > > We will be taking memcache offline tomorrow morning from 9-10am PST
> > > (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> > > throw exceptions but will instead return false for set() calls and
> > > None for get() calls (just like any other cache miss.)
>
> > > Your app should continue serving normally during this period, and
> > > we'll keep you updated on our progress. "
>
> > > Additonally, I'd like to make two suggestions:
> > > 1. If you're going to take down memcache, wouldn't it make sense to
> > > remove the quota limits?  It hardly seems fair to penalized for
> > > exceeding quota when caching is disabled.
>
> > > 2.  If you have to take down our apps for an hour, can you pick
> > > something like 2am - 3am?  I know you don't want to go to work at 2am,
> > > but it's not really ok to take down our apps for an hour during prime-
> > > time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.

[google-appengine] Re: ReferenceProperty could avoid unnecesary resolve

[Chris Marasti-Georg]

Wooble, that's incorrect.  The solution is here:
http://stackoverflow.com/questions/141973/how-do-i-get-the-key-value-of-a-dbreferenceproperty-without-a-database-hit

On Thu, Nov 13, 2008 at 11:04 AM, Wooble <[EMAIL PROTECTED]> wrote:

>
> How would that be more efficient?  The entity isn't fetched until you
> try to use it as an instance anyway.
>
> On Nov 13, 10:42 am, tigrillo <[EMAIL PROTECTED]>
> wrote:
> > For the sake of efficient, it will be nice if ReferenceProperty let's
> > us return the Key optionally instead of the Entity.
> >
> > Thanks
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Gayle Laakmann]

It was timing out within memcache.get and memcache.set -
consistently.  If I understand you correctly - you're saying that
memcache isn't technically timing out, on the grounds that it would
complete if given enough time.  But, the cache misses take SO much
time that it consistently timeouts during the operations of
memcache.get and memcache.set.

Ok, sure, that may be the case.  I'm afraid I don't really see the
difference between that and timing out.  Either way, memcache.get and
memcache.set aren't exactly just "return false and letting your
application proceed."  The fact is they are causing timeouts.

obj = memcache.get(cache_key)
  File "/base/data/home/apps/careercup/13.329261908074364999/memcache/
__init__.py", line 362, in get
self._make_sync_call('memcache', 'Get', request, response)

  File "/base/python_lib/versions/1/google/appengine/api/
apiproxy_stub_map.py", line 46, in MakeSyncCall
stub.MakeSyncCall(service, call, request, response)
  File "/base/python_lib/versions/1/google/appengine/runtime/
apiproxy.py", line 245, in MakeSyncCall

rpc.Wait()
  File "/base/python_lib/versions/1/google/appengine/runtime/
apiproxy.py", line 161, in Wait
rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)


On Nov 13, 9:45 am, Brett <[EMAIL PROTECTED]> wrote:
> Hi Gayle,
>
> I'm sorry to hear you're seeing issues. It's important to note that
> there are two types of DeadlineExceededErrors. One is defined in
> apiproxy_errors.py. The other is in runtime/__init__.py:
>
> http://code.google.com/p/googleappengine/source/browse/trunk/google/a...
>
> The names are the same, which makes this confusing. The latter error
> is raised when the request has been processing for too long (~10
> seconds). Perhaps what's happening here is that the cache misses are
> causing a lot of extra work to be done, causing your application to
> hit this other deadline.
>
> The traceback sent by Pratham confirms this behavior. More detail on
> how to deal with this is here, in the section entitled "The Request
> Timer":
>
> http://code.google.com/appengine/docs/python/requestsandcgi.html
>
> -Brett
>
> On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > Despite what the post at the link below says, memcache is actually
> > timing out and throwing a DeadlineExceededError.  Furthermore, it
> > hardly seems accurate to say that our apps should continue serving
> > normally.  The quota limits are so ridiculously low that we CAN'T
> > serve pages without caching.
>
> >http://groups.google.com/group/google-appengine-downtime-notify/brows...
> > We will be taking memcache offline tomorrow morning from 9-10am PST
> > (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> > throw exceptions but will instead return false for set() calls and
> > None for get() calls (just like any other cache miss.)
>
> > Your app should continue serving normally during this period, and
> > we'll keep you updated on our progress. "
>
> > Additonally, I'd like to make two suggestions:
> > 1. If you're going to take down memcache, wouldn't it make sense to
> > remove the quota limits?  It hardly seems fair to penalized for
> > exceeding quota when caching is disabled.
>
> > 2.  If you have to take down our apps for an hour, can you pick
> > something like 2am - 3am?  I know you don't want to go to work at 2am,
> > but it's not really ok to take down our apps for an hour during prime-
> > time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] django.dispatch.errors.DispatcherKeyError

[Denis]

All my request that go through Django throw this exception:
: 'No receivers
found for signal  from sender
_Any'

Traceback (most recent call last):
  File "/base/data/home/apps//96.1/main.py", line 26, in

django.core.signals.got_request_exception)
  File "/base/python_lib/versions/1/django/dispatch/dispatcher.py",
line 213, in disconnect
sender

All non-Django stuff works well.

line 26 is:
django.dispatch.dispatcher.disconnect
(django.db._rollback_on_exception,
 
django.core.signals.got_request_exception)

Are migrating to Django 1.0??

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[gee]

I second Gayle's points entirely.

We're getting hit with a huge number of deadline exceeded errors at
the moment, all due more or less to cache misses.

Site is basically unusable for our users.

Gee



On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> Despite what the post at the link below says, memcache is actually
> timing out and throwing a DeadlineExceededError.  Furthermore, it
> hardly seems accurate to say that our apps should continue serving
> normally.  The quota limits are so ridiculously low that we CAN'T
> serve pages without caching.
>
> http://groups.google.com/group/google-appengine-downtime-notify/brows...
> We will be taking memcache offline tomorrow morning from 9-10am PST
> (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> throw exceptions but will instead return false for set() calls and
> None for get() calls (just like any other cache miss.)
>
> Your app should continue serving normally during this period, and
> we'll keep you updated on our progress. "
>
> Additonally, I'd like to make two suggestions:
> 1. If you're going to take down memcache, wouldn't it make sense to
> remove the quota limits?  It hardly seems fair to penalized for
> exceeding quota when caching is disabled.
>
> 2.  If you have to take down our apps for an hour, can you pick
> something like 2am - 3am?  I know you don't want to go to work at 2am,
> but it's not really ok to take down our apps for an hour during prime-
> time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Pratham]

They're timing out for me as well

App-ID - lifesizedpicx

:
Traceback (most recent call last):
  File "/base/data/home/apps/lifesizedpicx/4.26/home.py", line 1316,
in main
run_wsgi_app (application)
  File "/base/python_lib/versions/1/google/appengine/ext/webapp/
util.py", line 76, in run_wsgi_app
result = application(env, _start_response)
  File "/base/python_lib/versions/1/google/appengine/ext/webapp/
__init__.py", line 499, in __call__
handler.get(*groups)
  File "/base/data/home/apps/lifesizedpicx/4.26/home.py", line 1078,
in get
memcache.set ('pic'+id, pix, CACHE_EXPIRE)
  File "/base/python_lib/versions/1/google/appengine/api/memcache/
__init__.py", line 539, in set
return self._set_with_policy(MemcacheSetRequest.SET, key, value,
time=time)
  File "/base/python_lib/versions/1/google/appengine/api/memcache/
__init__.py", line 609, in _set_with_policy
self._make_sync_call('memcache', 'Set', request, response)
  File "/base/python_lib/versions/1/google/appengine/api/
apiproxy_stub_map.py", line 46, in MakeSyncCall
stub.MakeSyncCall(service, call, request, response)
  File "/base/python_lib/versions/1/google/appengine/runtime/
apiproxy.py", line 245, in MakeSyncCall
rpc.Wait()
  File "/base/python_lib/versions/1/google/appengine/runtime/
apiproxy.py", line 161, in Wait
rpc_completed = _apphosting_runtime___python__apiproxy.Wait(self)

On Nov 13, 10:37 pm, Pete Koomen <[EMAIL PROTECTED]> wrote:
> Hi Gayle,
>
> Would you mind sending either your app_id or a stack trace to
> [EMAIL PROTECTED]  We haven't seen this globally and would like to
> look into it.
>
> Thanks!
> Pete, App Engine Team
>
> On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
>
> > Despite what the post at the link below says, memcache is actually
> > timing out and throwing a DeadlineExceededError.  Furthermore, it
> > hardly seems accurate to say that our apps should continue serving
> > normally.  The quota limits are so ridiculously low that we CAN'T
> > serve pages without caching.
>
> >http://groups.google.com/group/google-appengine-downtime-notify/brows...
> > We will be taking memcache offline tomorrow morning from 9-10am PST
> > (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> > throw exceptions but will instead return false for set() calls and
> > None for get() calls (just like any other cache miss.)
>
> > Your app should continue serving normally during this period, and
> > we'll keep you updated on our progress. "
>
> > Additonally, I'd like to make two suggestions:
> > 1. If you're going to take down memcache, wouldn't it make sense to
> > remove the quota limits?  It hardly seems fair to penalized for
> > exceeding quota when caching is disabled.
>
> > 2.  If you have to take down our apps for an hour, can you pick
> > something like 2am - 3am?  I know you don't want to go to work at 2am,
> > but it's not really ok to take down our apps for an hour during prime-
> > time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: 502 Bad Gateway on XMLHttpRequest from Firefox Extension

[Gijsbert]

The Google Labs team and Marzia discovered that I was using an
improper boundary string in the construction of my multipart/form-data
body. My separator was this:

  var filenameTimestamp = (new Date().getTime());
  var separator = "--12345 multipart boundary " +
filenameTimestamp;
  ...
  req.setRequestHeader("Content-type", "multipart/form-data;
boundary=" + separator);

ie with spaces, but the separator was not quoted in the Content-type.
Seems like lots of servers don't mind the spaces, but it is not
correct.

Removing the spaces from the separator fixed the problem.

Thanks!

On Nov 10, 4:35 pm, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Do you have the exact contents of one of these requests available?  Also the
> app id and domain name would be helpful.  As always, if you aren't
> comfortable providing this info in the groups, you can reply with it
> directly to me.
>
> -Marzia
>
> On Sat, Nov 8, 2008 at 12:37 PM, Gijsbert <[EMAIL PROTECTED]>wrote:
>
>
>
> > Hi,
>
> > I have a Firefox extension that sends an XMLHttpRequest multipart/form-
> > data request to my GAE application to upload a png screengrab (request
> > uses code taken from
> >http://blog.footle.org/2007/07/31/binary-multipart-posts-in-javascript/).
> > All is well on my dev server and on .appspot.com.
> > However, sending the same request to the same app through my own
> > domain (registered through Google Apps, CNAME with ghs.google.com)
> > gives me HTTP status 502 Bad Gateway after about 20 seconds. The
> > message body has some blurp about temporary error and try again in 30
> > seconds, but retrying gives the same result.
>
> > Does anybody have an idea on how to debug this further?
> > The logs on the admin console on appspot.com does not show any
> > activity for these requests. And the logs for the same request to
> > appspot.com look fine, they don't take very long (<400ms,
> > <1000mcycles) and return less than 1KB json status (I am testing with
> > small screengrabs, so the form-data is < 10KB).
> > I believe ghs.google.com proxies requests, is there some restriction
> > there?
>
> > Thanks,
> > Gijsbert
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Brett]

Hi Gayle,

I'm sorry to hear you're seeing issues. It's important to note that
there are two types of DeadlineExceededErrors. One is defined in
apiproxy_errors.py. The other is in runtime/__init__.py:

http://code.google.com/p/googleappengine/source/browse/trunk/google/appengine/runtime/__init__.py

The names are the same, which makes this confusing. The latter error
is raised when the request has been processing for too long (~10
seconds). Perhaps what's happening here is that the cache misses are
causing a lot of extra work to be done, causing your application to
hit this other deadline.

The traceback sent by Pratham confirms this behavior. More detail on
how to deal with this is here, in the section entitled "The Request
Timer":

http://code.google.com/appengine/docs/python/requestsandcgi.html



-Brett

On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> Despite what the post at the link below says, memcache is actually
> timing out and throwing a DeadlineExceededError.  Furthermore, it
> hardly seems accurate to say that our apps should continue serving
> normally.  The quota limits are so ridiculously low that we CAN'T
> serve pages without caching.
>
> http://groups.google.com/group/google-appengine-downtime-notify/brows...
> We will be taking memcache offline tomorrow morning from 9-10am PST
> (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> throw exceptions but will instead return false for set() calls and
> None for get() calls (just like any other cache miss.)
>
> Your app should continue serving normally during this period, and
> we'll keep you updated on our progress. "
>
> Additonally, I'd like to make two suggestions:
> 1. If you're going to take down memcache, wouldn't it make sense to
> remove the quota limits?  It hardly seems fair to penalized for
> exceeding quota when caching is disabled.
>
> 2.  If you have to take down our apps for an hour, can you pick
> something like 2am - 3am?  I know you don't want to go to work at 2am,
> but it's not really ok to take down our apps for an hour during prime-
> time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] n00b problem: can't print member values

[faber]

I think I'm missing something really simple here but I can't see
what.  I have an object I'm calling ProgressEvent (PE) which is a
db.Model that I've successfully written and stored.  I am now writing
a function to show all the PEs in the datastore, so I wrote this:

class showProgressEvents(webapp.RequestHandler):
def get(self):
query = ProgressEvent.all()
pevents = query.fetch(10)

self.response.out.write("Showing events:\n")

for pevent in pevents: # I've also used "for pevent in query:"
self.response.out.write(pevent.key)
self.response.out.write("\n")

But all it ever prints is:
Showing events:



The number of lines printed is correct. What am I missing?

--

faber

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Denis]

Pete,

  Please also check this post:
http://groups.google.com/group/google-appengine/browse_thread/thread/d8a3a54df62e1b04

  I guess, you've messed something up with versions.

Denis

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: import nltk libraries in appengine

[Jeff S]

Hi Alex,

I'm not familiar with NLTK but in general the way to include Python
libraries in your app is to place the source code in the top level
directory of your app so that it is uploaded along with your app's
code. Your app's directory structure might look something like this:

app_name/
  |- app.yaml
  |- 
  |- ntlk
 |- chat
 |- chunk
 |- classify
 |- ...

If NLTK has other Python libraries which it depends on, those will
also need to be included in your app. If these libraries are not pure
Python (contain C code) then you will not be able to use them on App
Engine.

http://code.google.com/appengine/kb/commontasks.html#thirdparty

Happy coding,

Jeff



On Nov 12, 7:42 am, alexarsh <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have appengine project and I would like to use nltk libraries.
> Can someone give me a step by step instructions how to include nltk
> libraries to my project in order to be able to do "import nltk" from
> my appengine project?
>
> Thanks, Alex Arshavski.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: User login problem

[Jeff S]

Hi Giacomo,

I want to make sure I've understood your design. You said you want a
page listing your Google Docs, and this listing page would not require
users to log in, in other words, it is public. Do you want everyone to
be able to view the doc content as well? This should be doable if you
are using client login and embedding the global account's credentials
in the code.

If your app is asking users to log in, then the cause may be that a
URL is marked login:required in app.yaml, or perhaps a request handler
is automatically redirecting to a sign in page. I might be able to get
a better idea if I could look at some of your code.

Thank you,

Jeff

On Nov 12, 12:22 am, Giacomo Cucciati <[EMAIL PROTECTED]>
wrote:
> Hi all!
>
> I have a problem linked to the user login...
>
> My web application should work in this way:
> -an external user visits my web page were there are some links
> -each of these shows a list of my documents (using Docs API)
> -each doc title, shown in the list, is a link to the doc content
>
> Now, when i have updated my application (by appcfg.py command) I have
> seen
> that an external user has to login with his google account whene he
> clicks on a link to obtain
> just the list of my docs, otherwise an authentication error occours.
> The credentials of my account for the client login (mail and password)
> are inserted in the code so it isn't their fault.
> I know there is the users.create_login_url(self.request.uri)
> function... but is there a way to avoid the user login page or to
> create a fake user (to insert in the code as the previous one) so that
> everyone can see my document list?
>
> I'm not sure to have explaned clearly the problem...
>
> Thank you!
>
> Giacomo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Memcache API Timing out

[Pete Koomen]

Hi Gayle,

Would you mind sending either your app_id or a stack trace to
[EMAIL PROTECTED]  We haven't seen this globally and would like to
look into it.

Thanks!
Pete, App Engine Team

On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> Despite what the post at the link below says, memcache is actually
> timing out and throwing a DeadlineExceededError.  Furthermore, it
> hardly seems accurate to say that our apps should continue serving
> normally.  The quota limits are so ridiculously low that we CAN'T
> serve pages without caching.
>
> http://groups.google.com/group/google-appengine-downtime-notify/brows...
> We will be taking memcache offline tomorrow morning from 9-10am PST
> (GMT-8) for routine maintenance.  Calls to the memcache API will *not*
> throw exceptions but will instead return false for set() calls and
> None for get() calls (just like any other cache miss.)
>
> Your app should continue serving normally during this period, and
> we'll keep you updated on our progress. "
>
> Additonally, I'd like to make two suggestions:
> 1. If you're going to take down memcache, wouldn't it make sense to
> remove the quota limits?  It hardly seems fair to penalized for
> exceeding quota when caching is disabled.
>
> 2.  If you have to take down our apps for an hour, can you pick
> something like 2am - 3am?  I know you don't want to go to work at 2am,
> but it's not really ok to take down our apps for an hour during prime-
> time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: SproutCore app on AppEngine, authentication concerns

[Charles Jolley]

Hi Devraj,

You can setup a proxy from sc-server to your AppEngine.  This way you
can visit localhost:4020 and you should be able to work from there.
You can find the samplecode for http://sproutcore-demo.appspot.com at:

http://github.com/sproutit/samples-todos/tree/step-6

Look the servers/sproutcore-demo directory for the AppEngine code.
There is also a Merb server in there.  The rest is SproutCore code.

-Charles

On Nov 13, 2:00 am, "Devraj Mukherjee" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Our app engine application is going to use SproutCore as its
> JavaScript framework. As SproutCore or JavaScript sits quite
> independently of App Engine or any server side technology we are
> assuming that this should work 
> (actuallyhttp://sproutcore-demo.appspot.com/confirms that it should not be a
> problem).
>
> Authentication should be quite simple as well, as long as both our
> HTML/JS deliver and REST services use Google authentication its should
> all work fine.
>
> The question is while developing the SproutCore application we need to
> run two dev servers, so if our rest services required authentication
> and we deliver our SproutCore app from the SC dev server how can we
> test that everything works? Although the two dev servers are running
> at different ports do they still honour the cookies set by the domain
> (localhost)?
>
> Our application is user centric so we will require the user to login.
>
> Any SproutCore / App Engine developers out there that could give me a
> few pointers?
>
> Thanks for your time.
>
> --
> "I never look back darling, it distracts from the now", Edna Mode (The
> Incredibles)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Memcache API Timing out

[Gayle Laakmann]

Despite what the post at the link below says, memcache is actually
timing out and throwing a DeadlineExceededError.  Furthermore, it
hardly seems accurate to say that our apps should continue serving
normally.  The quota limits are so ridiculously low that we CAN'T
serve pages without caching.

http://groups.google.com/group/google-appengine-downtime-notify/browse_thread/thread/77cfc8980acd6873/28a397a9fc65420f#28a397a9fc65420f
We will be taking memcache offline tomorrow morning from 9-10am PST
(GMT-8) for routine maintenance.  Calls to the memcache API will *not*
throw exceptions but will instead return false for set() calls and
None for get() calls (just like any other cache miss.)

Your app should continue serving normally during this period, and
we'll keep you updated on our progress. "


Additonally, I'd like to make two suggestions:
1. If you're going to take down memcache, wouldn't it make sense to
remove the quota limits?  It hardly seems fair to penalized for
exceeding quota when caching is disabled.

2.  If you have to take down our apps for an hour, can you pick
something like 2am - 3am?  I know you don't want to go to work at 2am,
but it's not really ok to take down our apps for an hour during prime-
time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Reminder: Scheduled Maintenance This Evening

[Scott Mahr]

My app worked yesterday, and now is down as well.   id=o24u
If I roll back to before I used memcache would it fix it?  Any idea on
when this will be ironed out?

sample log entry
11-13 09:19AM 20.397 / 500 9068ms 4122mcycles 0kb
66.215.95.164 - - [13/11/2008:09:19:29 -0800] "GET / HTTP/1.1" 500 0 -
-
E 11-13 09:19AM 29.461
Traceback (most recent call last):
E 11-13 09:19AM 29.461
  File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line 92,
in run
E 11-13 09:19AM 29.461
:
Traceback (most recent call last):
  File "/base/data/home/apps/o24u/3.7/o24umain.py", line 804, in

main()
  File "/base/data/home/apps/o24u/3.7/o24umain.py", line 802, in main
wsgiref.handlers.CGIHandler().run(application)
  File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line 96,
in run
self.handle_error()
  File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line
306, in handle_error
self.log_exception(sys.exc_info())
  File "/base/python_dist/lib/python2.5/wsgiref/handlers.py", line
298, in log_exception
self.traceback_limit, stderr
  File "/base/python_dist/lib/python2.5/traceback.py", line 125, in
print_exception
print_tb(tb, limit, file)
  File "/base/python_dist/lib/python2.5/traceback.py", line 70, in
print_tb
if line: _print(file, '' + line.strip())

On Nov 12, 11:58 am, heidmotron <[EMAIL PROTECTED]> wrote:
> When I try to memcache django's QueryPaginator object I'm getting:
>
> PicklingError: Can't pickle : it's not found as
> __builtin__.instancemethod
>
> It was working before yesterday. Is there something new I should be
> doing?
>
> On Nov 11, 11:30 pm, Arun Shanker Prasad <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
>
> >   Still getting the same error even with setting the value in a list.
>
> > Thanks,
> > Arun Shanker Prasad.
>
> > On Nov 12, 11:22 am, Arun Shanker Prasad <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi,
>
> > >  Regarding you option to set the value as a list this is not causing
> > > any issue and got it working by changing the code. Was this modified
> > > during the current modification? Because I can still get the same code
> > > to work in the SDK..
>
> > > Thanks,
> > > Arun Shanker Prasad.
>
> > > On Nov 12, 10:32 am, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
>
> > > > It seems like this error is most likely caused as the result of 
> > > > pickling a
> > > > Query object instead of the results of a query.  Are engineering team is
> > > > looking in to this issue.
>
> > > > -Marzia
>
> > > > On Tue, Nov 11, 2008 at 9:20 PM, Arun Shanker Prasad <
>
> > > > [EMAIL PROTECTED]> wrote:
>
> > > > > Hi,
>
> > > > >  My app id is space1. I am putting the parentModel.child_set list
> > > > > into memcahce.
>
> > > > > Thanks,
> > > > > Arun Shanker Prasad.
>
> > > > > On Nov 12, 10:16 am, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
> > > > > > Also, what are you placing in Memcache when your application is 
> > > > > > showing
> > > > > this
> > > > > > error?
>
> > > > > > -Marzia
>
> > > > > > On Tue, Nov 11, 2008 at 9:15 PM, Marzia Niccolai <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > > Hi,
>
> > > > > > > What is the app id that is experiencing this issue?
>
> > > > > > > -Marzia
>
> > > > > > > On Tue, Nov 11, 2008 at 9:13 PM, Arun Shanker Prasad <
> > > > > > > [EMAIL PROTECTED]> wrote:
>
> > > > > > >> Hi,
> > > > > > >>       Also the error I got was "PicklingError" during the 
> > > > > > >> memcache
> > > > > > >> set. This was working last night
> > > > > > >> Thanks,
> > > > > > >> Arun Shanker Prasad.
>
> > > > > > >> On Nov 12, 9:54 am, Marzia Niccolai <[EMAIL PROTECTED]> wrote:
> > > > > > >> > Hi,
>
> > > > > > >> > Another issue occurred during scheduled maintenance tonight, 
> > > > > > >> > which
> > > > > is
> > > > > > >> not
> > > > > > >> > related to the issue mentioned above.
>
> > > > > > >> > This issue affected objects stored in Memcache.  If your 
> > > > > > >> > application
> > > > > was
> > > > > > >> > affected by this error, you would not have been individually
> > > > > emailed.
>
> > > > > > >> > If your application is currently experiencing issues, it is 
> > > > > > >> > most
> > > > > likely
> > > > > > >> > related to the Memcache issue which our engineering team is
> > > > > currently
> > > > > > >> > investigating.  You should see an AttributeError in your
> > > > > application's
> > > > > > >> logs.
>
> > > > > > >> > We expect this issue will be fixed shortly.
>
> > > > > > >> > -Marzia
>
> > > > > > >> > On Tue, Nov 11, 2008 at 8:24 PM, Gayle Laakmann <[EMAIL 
> > > > > > >> > PROTECTED]>
> > > > > > >> wrote:
>
> > > > > > >> > > My site (http://www.careercup.com) is down.  I did not get an
> > > > > email.
>
> > > > > > >> > > On Nov 11, 7:44 pm, Marzia Niccolai <[EMAIL PROTECTED]> 
> > > > > > >> > > wrote:
> > > > > > >> > > > Hi,
>
> > > > > > >> > > > Our engineers are working as quickly as possible to restore
> > > > > > >> > > functionality.
> > > > > > >> > > > A small number of applicatio

[google-appengine] Re: App Engine App Engine outputting INVALID xHTML code - according to validator.w3.org - URL which contains an ampersand

[HG]

Rodrigo:

. THANKS for such a fast response.

>> To avoid this, mark the  url as "safe". In the Hello World example:
>> {{ url_linktext }}

. I tried that but same problem with validation. I wonder if you meant
"escape"

. With the information you provided I found:
  http://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs
  and tried this:
   {{ url_linktext }}
  and now ALL is 100% valid.

Thanks again...

Rob




On Nov 13, 10:37 am, "Rodrigo Moraes" <[EMAIL PROTECTED]>
wrote:
> On Thu, Nov 13, 2008 at 1:16 PM, HG wrote:
> > Errors relate to:
> > - Common error occurs when including a URL which contains an ampersand
> > ("&"):
>
> > - This is invalid!  ...
> >  This example generates an error for "unknown entity section" because
> > the "&" is assumed to begin an entity reference.
>
> I think django template is automatically escaping the url (feature,
> not bug, since most variables need escaping). To avoid this, mark the
> url as "safe". In the Hello World example:
>
>     {{ url_linktext }}
>
> -- rodrigo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: ReferenceProperty could avoid unnecesary resolve

[Wooble]

How would that be more efficient?  The entity isn't fetched until you
try to use it as an instance anyway.

On Nov 13, 10:42 am, tigrillo <[EMAIL PROTECTED]>
wrote:
> For the sake of efficient, it will be nice if ReferenceProperty let's
> us return the Key optionally instead of the Entity.
>
> Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: App Engine App Engine outputting INVALID xHTML code - according to validator.w3.org - URL which contains an ampersand

[Rodrigo Moraes]

On Thu, Nov 13, 2008 at 1:16 PM, HG wrote:
> Errors relate to:
> - Common error occurs when including a URL which contains an ampersand
> ("&"):
>
> - This is invalid!  ...
>  This example generates an error for "unknown entity section" because
> the "&" is assumed to begin an entity reference.

I think django template is automatically escaping the url (feature,
not bug, since most variables need escaping). To avoid this, mark the
url as "safe". In the Hello World example:

{{ url_linktext }}

-- rodrigo

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] ReferenceProperty could avoid unnecesary resolve

[tigrillo]

For the sake of efficient, it will be nice if ReferenceProperty let's
us return the Key optionally instead of the Entity.

Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Copying local datastore

[Wooble]

On Nov 13, 9:28 am, Aramaki <[EMAIL PROTECTED]> wrote:
> ¿Is it possible to copy the content of my local database to the server
> one? It should be quite usefull in order to preload some data for my
> users

Not directly.  You could possibly have the app on the devserver use
urlfetch to post the data to the production server.  This may be
likely to get ugly.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] App Engine App Engine outputting INVALID xHTML code - according to validator.w3.org - URL which contains an ampersand

[HG]

Hi:

Just a quick question about valid xHTML code output.

I was curious if I am doing something wrong? Is there an easy way to
fix the issue?
(a search of this discussion board only yielded me info on 
validation issues ;(

The  Hello World example worked perfectly for me and was extremely
helpful.

However, I was expecting to get a perfectly valid xHTML page, which I
didn't
-
Problem Details:

Errors relate to:
- Common error occurs when including a URL which contains an ampersand
("&"):

- This is invalid!  ...
  This example generates an error for "unknown entity section" because
the "&" is assumed to begin an entity reference. Browsers often
recover safely from this kind of error, but real problems do occur in
some cases. In this example, many browsers correctly convert ©=3
to ©=3, which may cause the link to fail.

- Note that in most documents, errors related to entity references
will trigger up to 5 separate messages from the Validator. Usually
these will all disappear when the original problem is fixed.

See hello world errors at:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fmrmtest1.appspot.com%2F%23

Validation Output:  12 Errors
   1. Warning Line 133, Column 69: cannot generate system identifier
for general entity "continue".
  …com/accounts/ServiceLogin?service=ah&continue=http://
mrmtest1.appspot.com/_ah
etc.
-

I am thankful for any responses on this topic and I assume that
validation of output is important to many
users of App Engine.

Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: 有个想法，想写 个工具帮助自动生成AppEngine的项目文件

[yu ping322]

我不同意思，主要看你要做一个什么东东了，比如你写一个blog，你加一堆别人写的包有什么用，和你做的主题不相关啊。。。你有什么想法快速实现就好，不要加一堆不相关的，除丰你是想做一个门户网站之类，有很多栏目。很多功能。

2008/11/13 A. TNG <[EMAIL PROTECTED]>:
>
> Hi,
>
> Sorry guys. Make a mistake and send to wrong email address.
>
> --
> Best Regards,
> TANG Jiyu
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Copying local datastore

[Aramaki]

¿Is it possible to copy the content of my local database to the server
one? It should be quite usefull in order to preload some data for my
users

On Nov 13, 3:39 am, Peter Recore <[EMAIL PROTECTED]> wrote:
> also, you can maintain multiple datastore files and choose which one
> to use when you run dev_appserver.  there is a switch "--
> datastore_path" that lets you specify where to look for the datastore
> files.
>
> On Nov 12, 7:25 pm, Alexander Kojevnikov <[EMAIL PROTECTED]>
> wrote:
>
> > On Windows the files are  %TEMP%\dev_appserver.datastore and
> > dev_appserver.datastore.history
>
> > On Mac and Linux they are probably in /tmp
>
> > Just copy them to another machine, it should do the trick.
>
> > On Nov 13, 10:06 am, Nefarious <[EMAIL PROTECTED]> wrote:
>
> > > I have a new developer helping on my GAE project.  I would like him to
> > > have a copy of the local data I already have setup.  Have any of you
> > > moved this data?  If so, what files did you move and how did it go?
>
> > > Thanks,
>
> > > Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: IE can't display GAE web page while firefox can

[Alexandru Zbarcea]

what you have here is only the *Content Header* ...
... so i don't know if you receive from server anything else, like *Response
Content.

*I'm using *django* too! If you use django
helper,
then you should know that it works only with django 1.0, and appengine sdk
is available with django 0.96.

I don't really know how to make appengine to work with django 1.0 (i haven't
tried yet) ...
but you surely take a look at this
article
.

If you want to make it work visit samples or download
this
.

The example above is the source of inspiration for this
project
.

If you want me to help you look deeper into code ... please reply.

On Wed, Nov 12, 2008 at 3:37 PM, stack <[EMAIL PROTECTED]> wrote:

>
> Hi, I'm developing an app on GAE. At first, I was using web framework
> from GAE, everything was fine. Then I started using django framework
> and followed the instructions of an article from official site of GAE
> (Running Django on Google App Engine), then strange things happened.
>
> All my dynamic web page(which is handled by a python script and
> rendered through a django template) can display on firefox, everything
> is ok, however, none of them can display on IE, the strange part is
> I'm sure IE has already got the content of the web page, css files and
> other stuff.
>
> At first, I thought, maybe it just happened because i used a
> dev_server of GAE, then I update the app to GAE, still the same.
>
> Then I checked html request/response(static file can all be displayed
> by IE),  and found nothing unusual, for example
> this is request/response for a dynamic web page
> GET / HTTP/1.1
> Accept: */*
> Accept-Language: zh-cn
> UA-CPU: x86
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET
> CLR 1.1.4322; .NET CLR 2.0.50727)
> Host: localhost:8080
> Connection: Keep-Alive
>
> HTTP/1.0 200 OK
> Server: Development/1.0 Python/2.5.1
> Date: Wed, 12 Nov 2008 13:24:53 GMT
> Content-Type: text/html; charset=utf-8
> Cache-Control: no-cache
> content-length: 2701
>
> this is request/response for static html file:
> GET /htdocs/help.html HTTP/1.1
> Accept: */*
> Accept-Language: zh-cn
> UA-CPU: x86
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET
> CLR 1.1.4322; .NET CLR 2.0.50727)
> Host: localhost:8080
> Connection: Keep-Alive
>
> HTTP/1.0 200
> Server: Development/1.0 Python/2.5.1
> Date: Wed, 12 Nov 2008 13:34:43 GMT
> Content-type: text/html
> Expires: Wed, 19 Nov 2008 13:34:43 GMT
> Cache-Control: public, max-age=604800
> content-length: 263
>
> they all look the same to me. Anyone could think of solution to this
> problem? Any help would be appreciated. Thanks very much!
>
> >
>


-- 

Malcolm Forbes

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Background image not showing in Firefox when accessed through dev_appserver

[TLH]

I cannot reproduce your results.

I am using Firefox 3.0.3 on Ubuntu.

Here is my app.yaml:

 snip 
application: cssurl
version: 1
api_version: 1
runtime: python

handlers:
- url: /stylesheets
  static_dir: stylesheets

- url: /images
  static_dir: images

- url: /.*
  script: cssurl.py

 snip 

here is my stylesheet:

 snip 

div#one {
background-image: url('/images/one.jpeg')
}
div#two {
background-image: url('/images/two.jpeg')
}
div#three {
background-image: url('/images/three.jpeg')
 }
div#four {
background-image: url('/images/four.jpeg')
 }

div.imgrow div {
width: 192px;
height: 256px;
float: left;
   }

div.imgrow {
width: 800px;
height: 280px;

   }

div#footer {
clear: both;
   }

 snip 

Here is my template, index.html:

 snip 
http://www.w3.org/TR/html4/strict.dtd";>




css background images




one


two


three


four



Ta-daa!



 snip 

Here is my handler:

 snip 

import os
from google.appengine.ext.webapp import template
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

class MainPage(webapp.RequestHandler):
def get(self):
template_values = {
}

path = os.path.join(os.path.dirname(__file__), 'index.html')
self.response.out.write(template.render(path,
template_values))


application = webapp.WSGIApplication(
[
('/', MainPage),
],
debug=True)

def main():
run_wsgi_app(application)

if __name__ == "__main__":
main()

snip

Does this work for you?

On Nov 12, 1:20 pm, aunindo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In html template, I have some background images through inline css in
> the table tag.
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: 有个想法，想写 个工具帮助自动生成AppEngine的项目文件

[A . TNG]

Hi,

Sorry guys. Make a mistake and send to wrong email address.

-- 
Best Regards,
TANG Jiyu

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] 有个想法，想写个工具 帮助自动生成AppEngine的项目文件

[A . TNG]

Hi All,

最近练习GAE，写了几个小程序，不过也有一些感受，今天蹦出来个想法，跟大家分享一下。

遇到的问题：
感觉开发GAE的程序，确实比较简单，依靠python得天独厚的语言优势，开发过程也很开心。但是，例如我要重头开始构建一个AppEngine程序，还是有些麻烦。首先我要创建一个app.yaml，如果要自己写，需要记住yaml的语法，其实大多数时候，我都是从以前的一个项目里拷贝过来；要写一个main.py，还需要import一些class，我对那些class不是特别理解，每次也是依葫芦画瓢，或者直接拷贝，当我想实现一个提供简单功能的系统原型的时候，我更希望能立刻从功能函数开始写起。网络的牛牛们写了不少有趣的工具，例如，给appengine提供shell的功能；以及appfilebrowser，提供浏览源代码的功能；还有zipme，可以把整个站点的代码打成zip包，下载下来。这些功能都非常酷，很多时候，为了方便，我希望这些东西都在我的项目文件里面。但是不方便的是，我需要挨个下载，或者从本地的某个文件夹拷贝过来。在我想使用到AppEngine没有带的一些类库，或者想使用http://groups.google.com/group/google-appengine/web/google-app-engine-open-source-projects
提供的工具类库时，都需要手动来做。
我觉得，这个蛮麻烦的，很多都是重复的工作。

受到启发：
最近因为也用到的了YUI（一个js的webframework，
http://developer.yahoo.com/yui/），同样一个很酷的工具，最有意思的莫过于他的YUI Dependency
Configurator。YUI里面包含了各种各样的"控件"，每个控件由一些js和css组成，但是开发者们并不是每次都需要使用到所有的控件，而且一些控件之间还有依赖关系，与是YUI
Dependency 
Configurator就提供了一个页面，让用户自己选择需要的控件，然后他生成一段HTML代码，直接把它拷贝到你的页面里面，就可以使用YUI了。
有兴趣的可以看这里 http://developer.yahoo.com/yui/articles/hosting/ 。
于是我想，能不能也做一个类似的工具，功能大体是，页面列出了可以在GAE中用到的各类类库，用户可以根据自己的需求选择一些类库，然后点击一个按钮，从而得到一个zip包，里面包含常用的app.yaml,
main.py等一些默认的文件以及所需要的类库源代码，当然main.py里面已经有了初始的代码，即可立即开始实现原型系统了。

提供的方便：
1. 可以帮助初学者，减少入门AppEngine的门槛。
2. 方便一些有经验的人，节省重复劳动的时间。

暂时想了个名字，可以称为 gae-util-suit

不知道大家怎么看？或者有更好的解决方案？或者，觉得没这必要？
欢迎拍 :)

-- 
Best Regards,
TANG Jiyu

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Any way to create dynamic file

[Masa]

Actually now I got this working by modifying in pyExcelerator library
output stream to StringIO by my own custom function. Now the whole
thing works perfectly and I get nice Excel sheets out!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] weird/interesting "multiple entity groups" case

[Jay Freeman (saurik)]

I am  running into a confusing "can't operate on multiple entity groups in a 
single transaction" case when I am, in fact, not accessing "multiple entity 
groups". I think I understand what might be going on, but A) am not certain and 
B) others might find it interesting, anyway.

What is happening is that I have a transaction that is operating over two 
models: GoogleUser and Account. I get the GoogleUser instance associated with 
the current e-mail address with get_by_key_name and then return gooser.account. 
If I fail to find that GoogleUser, I add a new Account, and into the /same 
entity group/ I add the GoogleUser in question.

For reference, here is the actual code of my transaction:

132 @staticmethod
133 def goi_account_by_primary_key_(user, hash, **kw):
134 gooser = GoogleUser.get_by_key_name(hash)
135 if gooser:
136 account = db.get(gooser.account)
137 keys = kw.keys()
138 for key in keys:
139 setattr(account, key, kw[key])
140 account.put()
141 else:
142 account = Account(**kw)
143 account.put()
144 gooser = GoogleUser(parent=account, key_name=hash, 
user=user, account=account)
145 gooser.put()
146 return account

Note that moving the creation of the gooser above the creation of the account 
(and swapping the parent/child relationship between them and making other 
required code changes to temporarily support that) does work.

Why does this happen?

Currently my two theories are: A) the detection code is incorrect, and is 
making assumptions about "same model", and B) entities that don't exist yet are 
only considered in the same entity group as that entity itself, so even though 
I'm going to create that entity later into the same entity group, I can't put a 
different object first as the data store can't tell the difference. I am 
guessing that B is correct, in which case maybe someone else working on this 
same problem will find this post and be helped by it. If it isn't B, then maybe 
someone would be kind enough to tell me what the problem actually is ;P.

-J
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: SproutCore app on AppEngine, authentication concerns

[Devraj Mukherjee]

Hi Bill,

Thanks for your response.

On Thu, Nov 13, 2008 at 9:13 PM, Bill <[EMAIL PROTECTED]> wrote:
>
> Why do you need need two dev servers?  From what I understand of
> SproutCore, you generate a bunch of static files that will be served
> up by either your local App Engine server (during development) or your
> production App Engine server in the cloud.  Since the REST calls and
> static SC files are served from the same server, there's no problem
> with authentication cookies.  So I'm not sure why your SC dev server !
> = the App Engine server with REST services.

My understanding of SproutCore is that you need the dev server as it
uses the Ruby templating language and thus the use o sc-server and
once you are done you use sc-build to spit out the static JS.

During development it might easier to use the sc-server?

Or am I completely missing something here?


-- 
"I never look back darling, it distracts from the now", Edna Mode (The
Incredibles)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: SproutCore app on AppEngine, authentication concerns

[Bill]

Why do you need need two dev servers?  From what I understand of
SproutCore, you generate a bunch of static files that will be served
up by either your local App Engine server (during development) or your
production App Engine server in the cloud.  Since the REST calls and
static SC files are served from the same server, there's no problem
with authentication cookies.  So I'm not sure why your SC dev server !
= the App Engine server with REST services.

On Nov 13, 2:00 am, "Devraj Mukherjee" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Our app engine application is going to use SproutCore as its
> JavaScript framework. As SproutCore or JavaScript sits quite
> independently of App Engine or any server side technology we are
> assuming that this should work 
> (actuallyhttp://sproutcore-demo.appspot.com/confirms that it should not be a
> problem).
>
> Authentication should be quite simple as well, as long as both our
> HTML/JS deliver and REST services use Google authentication its should
> all work fine.
>
> The question is while developing the SproutCore application we need to
> run two dev servers, so if our rest services required authentication
> and we deliver our SproutCore app from the SC dev server how can we
> test that everything works? Although the two dev servers are running
> at different ports do they still honour the cookies set by the domain
> (localhost)?
>
> Our application is user centric so we will require the user to login.
>
> Any SproutCore / App Engine developers out there that could give me a
> few pointers?
>
> Thanks for your time.
>
> --
> "I never look back darling, it distracts from the now", Edna Mode (The
> Incredibles)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] SproutCore app on AppEngine, authentication concerns

[Devraj Mukherjee]

Hi all,

Our app engine application is going to use SproutCore as its
JavaScript framework. As SproutCore or JavaScript sits quite
independently of App Engine or any server side technology we are
assuming that this should work (actually
http://sproutcore-demo.appspot.com/ confirms that it should not be a
problem).

Authentication should be quite simple as well, as long as both our
HTML/JS deliver and REST services use Google authentication its should
all work fine.

The question is while developing the SproutCore application we need to
run two dev servers, so if our rest services required authentication
and we deliver our SproutCore app from the SC dev server how can we
test that everything works? Although the two dev servers are running
at different ports do they still honour the cookies set by the domain
(localhost)?

Our application is user centric so we will require the user to login.

Any SproutCore / App Engine developers out there that could give me a
few pointers?

Thanks for your time.

-- 
"I never look back darling, it distracts from the now", Edna Mode (The
Incredibles)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] Re: service to regularly access a URL?

[[EMAIL PROTECTED]]

Thank you for your answer! I will link the gaeutilities page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---

[google-appengine] memcache unavailable tomorrow 9-10am PST; serving unaffected

[Ben Nevile]

Yikes - "serving unaffected" for me is exactly wrong! The way I've
architected one of my apps, without memcache my requests will pretty
much all timeout.  I will need to put the app "offline" for the
duration of the maintenance.

"We will be taking memcache offline tomorrow morning from 9-10am PST
(GMT-8) for routine maintenance."

Can I ask about the use of the phrase "routine maintenance"?  With all
due respect to your exciting and currently free product, can you
please confirm that as we move into a paid version of the service we
can expect this type of maintenance to be not routine, but the very
rare exception?

<3,
Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
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
-~--~~~~--~~--~--~---