[google-appengine] Re: Prerelease SDK 1.4.0 is out!
Why was the decision made to make this an app-wide one time only nuke button? I think enabling/disabling it in app.yaml per-upload would be much more useful. On Nov 23, 8:30 pm, Ikai Lan (Google) ikai.l+gro...@google.com wrote: You'll be able to download code, but anyone that wants to turn it off will be able to go to their admin dashboard and push a one-way, irreversible button to disallow this feature. Please do not depend on this feature to do source control. -- Ikai Lan Developer Programs Engineer, Google App Engine Blogger:http://googleappengine.blogspot.com Reddit:http://www.reddit.com/r/appengine Twitter:http://twitter.com/app_engine On Tue, Nov 23, 2010 at 11:12 AM, Sandeep Koduri sandeep.kod...@gmail.comwrote: Hello ikai, Thanks and congrats for the great release. Will there be an option for source code download control in app.yaml. according to the mail thread in pre-release of 1.3.8 we thought this will be implemented, and that would be very helpful. the feature announced now will be a very good add-on but, by default if the config is to be on app.yaml. Will there be any option for the creator of the app to get any versions source code. We have some use cases relying on this option. so please make a reply about this, accordingly we can streamline the development process at our team, Thanks On Fri, Nov 19, 2010 at 3:57 AM, Ikai Lan (Google) ikai.l+gro...@google.com ikai.l%2bgro...@google.com wrote: Hey everyone, I just wanted to let everyone know that prerelease SDK 1.4.0 is out! Get it from the Google Code project: http://code.google.com/p/googleappengine/downloads/list We're still working on the docs and will have them ready for the final release, so if there are any questions about how to use the new features, feel free to ask on this thread and I'll do my best to clarify them. The release notes are below. This is an EXCITING release: Python - The Always On feature allows applications to pay and keep 3 instances of their application always running, which can significantly reduce application latency. - Developers can now enable Warmup Requests. By specifying a handler in an app's app.yaml, App Engine will attempt to to send a Warmup Request to initialize new instances before a user interacts with it. This can reduce the latency an end-user sees for initializing your application. - The Channel API is now available for all users. - Task Queue has been officially released, and is no longer an experimental feature. The API import paths that use 'labs' have been deprecated. Task queue storage will count towards an application's overall storage quota, and will thus be charged for. - The deadline for Task Queue and Cron requests has been raised to 10 minutes. Datastore and API deadlines within those requests remain unchanged. - For the Task Queue, developers can specify task retry_parameters in their queue.yaml. - Metadata Queries on the datastore for datastore kinds, namespaces, and entity properties are available. - URLFetch allowed response size has been increased, up to 32 MB. Request size is still limited to 1 MB. - The Admin Console Blacklist page lists the top blacklist rejected visitors. - The automatic image thumbnailing service supports arbitrary crop sizes up to 1600px. - Overall average instance latency in the Admin Console is now a weighted average over QPS per instance. - The developer who uploaded an app version can download that version's code using the appcfg.py download_app command. This feature can be disabled on a per application basis in the admin console, under the 'Permissions' tab. Once disabled, code download for the application CANNOT be re-enabled. - Fixed an issue where custom Admin Console pages did not work for Google Apps for your Domain users. - Allow Django initialization to be moved to appengine_config.py to avoid Django version conflicts when mixing webapp.template with pure Django. http://code.google.com/p/googleappengine/issues/detail?id=1758 - Fixed an issue in the dev_appserver where get_serving_url did not work for transparent, cropped PNGs: http://code.google.com/p/googleappengine/issues/detail?id=3887 - Fixed an issue with the DatastoreFileStub. http://code.google.com/p/googleappengine/issues/detail?id=3895 Java - - The Always On feature allows applications to pay and keep 3 instances of their application always running, which can significantly reduce application latency. - Developers can now enable Warmup Requests. By specifying a handler in an app's appengine-web.xml, App Engine will attempt to to send a Warmup Request to initialize new instances before a user interacts with it. This can reduce the latency an end-user sees for initializing your application. - The
[google-appengine] Re: Prerelease SDK 1.4.0 is out!
If the guy uploading enables downloads to be malicious, he could equally just post up the code somewhere. That being said, I hadn't thought about the case of accidentally re- enabling and then having the account compromised. Even still, not being able to ever turn it back on seems short sighted. Perhaps a way to enable it similar to how disabling an app works, so it can't be done maliciously. On Nov 24, 6:07 pm, Barry Hunter barrybhun...@gmail.com wrote: Being a one time nuke, means its not possible to for a developer to accidentally (or maliciously) re enable downloads :) One of the main objections to 'download' is it makes it easier for someone who shouldnt get their hands on the source code. Yes the fact only the uploading developer gets it, makes it more secure, but not totally. Being able to turn off downloads, is another serious barrier to the 'thief'. Someone who as invested IP in their code, wants to be able to do everything possible to protect that. On 24 November 2010 16:25, Thomas Johansson prenc...@gmail.com wrote: Why was the decision made to make this an app-wide one time only nuke button? I think enabling/disabling it in app.yaml per-upload would be much more useful. On Nov 23, 8:30 pm, Ikai Lan (Google) ikai.l+gro...@google.com wrote: You'll be able to download code, but anyone that wants to turn it off will be able to go to their admin dashboard and push a one-way, irreversible button to disallow this feature. Please do not depend on this feature to do source control. -- Ikai Lan Developer Programs Engineer, Google App Engine Blogger:http://googleappengine.blogspot.com Reddit:http://www.reddit.com/r/appengine Twitter:http://twitter.com/app_engine On Tue, Nov 23, 2010 at 11:12 AM, Sandeep Koduri sandeep.kod...@gmail.comwrote: Hello ikai, Thanks and congrats for the great release. Will there be an option for source code download control in app.yaml. according to the mail thread in pre-release of 1.3.8 we thought this will be implemented, and that would be very helpful. the feature announced now will be a very good add-on but, by default if the config is to be on app.yaml. Will there be any option for the creator of the app to get any versions source code. We have some use cases relying on this option. so please make a reply about this, accordingly we can streamline the development process at our team, Thanks On Fri, Nov 19, 2010 at 3:57 AM, Ikai Lan (Google) ikai.l+gro...@google.com ikai.l%2bgro...@google.com wrote: Hey everyone, I just wanted to let everyone know that prerelease SDK 1.4.0 is out! Get it from the Google Code project: http://code.google.com/p/googleappengine/downloads/list We're still working on the docs and will have them ready for the final release, so if there are any questions about how to use the new features, feel free to ask on this thread and I'll do my best to clarify them. The release notes are below. This is an EXCITING release: Python - The Always On feature allows applications to pay and keep 3 instances of their application always running, which can significantly reduce application latency. - Developers can now enable Warmup Requests. By specifying a handler in an app's app.yaml, App Engine will attempt to to send a Warmup Request to initialize new instances before a user interacts with it. This can reduce the latency an end-user sees for initializing your application. - The Channel API is now available for all users. - Task Queue has been officially released, and is no longer an experimental feature. The API import paths that use 'labs' have been deprecated. Task queue storage will count towards an application's overall storage quota, and will thus be charged for. - The deadline for Task Queue and Cron requests has been raised to 10 minutes. Datastore and API deadlines within those requests remain unchanged. - For the Task Queue, developers can specify task retry_parameters in their queue.yaml. - Metadata Queries on the datastore for datastore kinds, namespaces, and entity properties are available. - URLFetch allowed response size has been increased, up to 32 MB. Request size is still limited to 1 MB. - The Admin Console Blacklist page lists the top blacklist rejected visitors. - The automatic image thumbnailing service supports arbitrary crop sizes up to 1600px. - Overall average instance latency in the Admin Console is now a weighted average over QPS per instance. - The developer who uploaded an app version can download that version's code using the appcfg.py download_app command. This feature can be disabled on a per application basis in the admin console, under the 'Permissions' tab. Once disabled, code download
[google-appengine] Re: Accessing Third Party Libraries from the Dev Server
There is a way using monkeypatching. I posted up a small howto over on StackOverflow: http://stackoverflow.com/questions/3086091/debug-jinja2-in-google-app-engine/3694434#3694434 The thing you need to know is the list of c modules you depend on so you can add them to the whitelist. - Tom On Sep 29, 9:55 pm, Nikola niko...@gmail.com wrote: Hello, I know GAE restricts access to allow only certain C libraries and Python modules. However, is there an easy way to lift those restrictions from the local dev server? Specifically, I would like to use the MySQLdb module to import my datastore data. Thanks, Nikola -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Is the 1M request limit too small?
HTTP requests are limited to 10MB, not 1MB. The APIs - including urlfetch - are still limited to 1MB however. If you look on the roadmap (http://code.google.com/appengine/docs/ roadmap.html) one of the features on deck is raising some API request/ response size limits. I'd be very surprised if urlfetch wasn't one of them. On Apr 2, 9:20 pm, Jeff Schnitzer j...@infohazard.org wrote: Storage density is going up, networks are getting faster, datasets are growing larger, and verbose text-based serialization formats are the dominant interchange format. 1 megabyte is starting to look awfully small. But this is the GAE limit for both URLFetch requests and for user-facing requests. I'm about to launch a feature that moves a lot of JSON-encoded polygon data through appengine. The vast majority of my requests will fit into 1M, but the outliers might get uncomfortably close to this limit. All it would take is several polygons with large numbers of points (or very long descriptions). First question: Does the 1M limit apply before or after gzipping? I'm guessing the answer is before, which is unfortunate because JSON polygon data will probably compress to a small fraction its original size. My clients will happily download a couple hundred k of polygon data if appengine can send it. Second question: Is it possible to start a discussion of raising this limit? Even just doubling to 2M would provide some breathing room. Thanks, Jeff -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Performance Profiling Url
There's a number of bugs with this, unless it has been fixed in 1.3.2 - Specifically: - The URL logged with each request is hardcoded to /stats. - Some URL's in the appstats UI link to /stats, hardcoded. - Some redirects in appstats are again, hardcoded. I tried overriding the setting in appengine_config.py, but it still did it. On Mar 31, 7:39 pm, Ikai L (Google) ika...@google.com wrote: Yes, the URI is easily configurable via app.yaml. On Wed, Mar 31, 2010 at 8:38 AM, Jody Belka j...@jj79.org wrote: So maybe use /debug/stats for the Appstats library? On 31 March 2010 16:32, vivpuri v...@vivekpuri.com wrote: Yes, and i am already using app.appspot.com/stats.* as part of my app -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: static files not found after upload
Are you trying to access the file from python? The static files are not served from the same servers, and as such are not accessible on the file system. On Mar 23, 2:05 am, Glenn Blackler glenn_black...@yahoo.com wrote: Hello -- My very simple app works fine on the dev server, but once uploaded it can't access a file in one of my static directories. I have a static directory HTML with two files in it. The first comes up fine (I redirect to it from .py script) but the other HTML file always brings an error when I try to link to it. The error in my log is -- Static file referenced by handler not found: html/new_task.html. I searched for others having this same problem, but the only ones I could find had to do with manage.py and django, which I don't think is the problem here. Again, everything works fine on the dev server which is why this is so frustrating. I appreciate any help. Here's my app.yaml if it helps : application: test_app version: 1 runtime: python api_version: 1 handlers: - url: /stylesheets static_dir: stylesheets - url: /html static_dir: html - url: /js static_dir: js - url: /tasks script: test2.py - url: /addnew script: test2.py - url: /.* script: home.py -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: 1500 ms query latency
Please get us an update on the actual issue (query latency) instead of just ignoring it. On Mar 5, 8:05 pm, Ikai L (Google) ika...@google.com wrote: Patrick, let us know if you do find any glaring differences. Nothing we've done yet has demonstrated that JDO/JPA introduces anything beyond negligible overhead to queries, but we're always in need of more good data. On Thu, Mar 4, 2010 at 11:47 PM, Patrick Twohig patr...@namazustudios.com wrote: Ikai, Off hand, no. Since I started using the low-level API, I've added lots of caching and the like so anything I could pull out of my code wouldn't exactly be a fair comparison. If I come across anything, I'll post it. When I was using JDO, I didn't see much that let me tune how aggressively it fetched entities from the datastore, which may have contributed to the frustrated I was having. I have had reasonably good success being able to adjust the fetching options manually. Pat. On Thu, Mar 4, 2010 at 11:56 AM, Ikai L (Google) ika...@google.com wrote: Patrick, do you have any examples of queries implemented using JDO/JPA versus the low-level API that can demonstrate that JDO/JPA queries introduce overhead? If you can post them, the datastore team will take a look at it. On Thu, Mar 4, 2010 at 9:49 AM, Patrick Twohig patr...@namazustudios.com wrote: Just a heads up, if you're using GAE/J and I've had much better performance with the low-level API over JDO/JPA. Pat. -- Patrick H. Twohig. Namazu Studios P.O. Box 34161 San Diego, CA 92163-4161 -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine http://googleappengine.blogspot.com|http://twitter.com/app_engine -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Patrick H. Twohig. Namazu Studios P.O. Box 34161 San Diego, CA 92163-4161 -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Can I Cancel Index Building
If you have old unused indexes (that is, removed from index.yaml and redeployed as you state), you can run `appcfg.py vacuum_indexes` to remove them. If they are stuck building, there's as far as I know not any way to get them removed, other than asking here on the forums. On Mar 6, 2:02 am, Jonny T jonn...@hotmail.com wrote: I added some indices to my app, and now its saying I'm over some limit. I removed the indices from my index.yaml, and redeployed but it still tells me its building the indices and I still get the errors. Can I cancel the building of these indices? It seems to be just sitting there and its taking my whole app down. I added some emergency code to just ignore some of the failures, but my app is basically unusable at this point. -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Billing and Quota Problem
Just a quick thought until you get an answer from support - Have you tried changing the budget just slightly (say, by a cent daily), perhaps that will fix things? On Feb 27, 5:04 pm, jread jr...@vendasta.com wrote: A further 24 hours has passed and our CPU quota on the app has _still_ not updated to match the budget we have set for it. On Feb 26, 10:07 am, jread jr...@vendasta.com wrote: Hi, Yesterday our demo app hit its CPU quota (appid: steprep-demo) so I went in and rebalanced the quota to allow for more CPU. The Cost / Budget column updated to show the new max value for CPU and based on that column we had capacity again. The available quota, however, remained at the level it was at before and stayed maxed out at 100%. I tried clicking through the Settings link to ensure that the quota had indeed been rebalanced and on that page it shows the increased CPU quota value which matches the monetary value that has been set. I ended up having to wait for the quota to reset itself in order to get our app back online. Even now, around 12 hours later, we are still seeing the same CPU quota value and the new monetary value. Any help is appreciated, Thanks, Jeff. -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Shorter load times since the outage?
Can't speak for others, but our load times have gone from on average 3-4 seconds from cold to 1-2 seconds, since the outage. The instances seem to live longer as well, but most importantly the cold start has been *much* better since then. On Feb 26, 7:11 pm, Ikai L (Google) ika...@google.com wrote: No, the outage wasn't related to a performance upgrade. There are any number of reasons why your application isn't being cycled out. I'm curious as to whether other users see this or if they see the opposite effect. On Fri, Feb 26, 2010 at 9:13 AM, Blake blakecaldw...@gmail.com wrote: I was seeing 7 second load times for my first request back into the system after the JVM (must have) went to sleep. Now it's super fast, as if the JVM wasn't sleeping. This is really great. Is anyone else seeing this too? I wonder if the outage was a side effect of a big performance push. -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: appcfg Server Error 500
Look at the very bottom of the quota details page; You are limited to 250 deployments per day. Always wondered why that quota was there, but if people have been doing what samba has been doing I don't blame them. No offense, I mean, but that's gotta be iffy for the appengine cluster to deal with. On Dec 22, 9:10 am, Panesse robert.pane...@gmail.com wrote: How did you learn that you had exceeded your quota for application updates? Are you sure this was the problem? On Dec 20, 6:04 am, samba cooldudevam...@gmail.com wrote: Found a fix, started using dyndns and pointed it to my local appengine sdk dev server. On Dec 20, 1:46 pm, samba cooldudevam...@gmail.com wrote: For normal webdev yes its ok, but in the context of facebook apps we need to supply fbml and receive post requests from/to facebook servers. And I can no way do this on my localmachine. So I have to upload every change to google appenine and ask facebook servers to interact with the facebook app on the appengine. On Dec 20, 9:47 am, Ben Bishop leo...@gmail.com wrote: Install the SDK on your local machine so you can develop, test and debug. When you've got a stable production version ready, deploy to App Engine. It's well worth the effort of installing the SDK - you'll find it a lot faster process of developing your apps. On Dec 20, 11:05 am, samba cooldudevam...@gmail.com wrote: I have been learning and writing appengine based facebook apps. The problem is you have to upload your code using appcfg every time you make a small modification. And today I ran out ofquotaof using --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: AppEngine says my model key is invalid
A key name is not the same as a key.
You need to use FooEntity.get_by_key_name to get a named entity.
Similarly, you need to set the key name at construction time, using
the key_name argument to the constructor.
On Dec 25, 10:25 pm, gmalquestion adatgyu...@gmail.com wrote:
Hi,
Here's the scenario:
I want to update the data on appengine by either modifying existing
model instances or adding new ones.
The uploaded data is in a format similar to this:
A0011,data fields
A0022,...
A0033,...
so the first column is a unique id and the rest is more data. My idea
was to fetch all model instances with the given IDs, update those
which exist already and add the others.
Here's the query when the data is posted:
keys = []
for row in data:
keys.append(db.Key(row[first_column]))
result = MyModel.get(keys)
the problem is appengine says to the db.Key(...) part that
File c:\Program Files\Google\google_appengine\google\appengine\api
\datastore_
types.py, line 169, in __init__
raise datastore_errors.BadKeyError('Invalid string key %s.' %
encoded)
BadKeyError: Invalid string key A0011.
It is true a model with this key does not exists yet in the db, but I
will set it as key_name when the model instance is created, since it
is unique, so why can't I use it for querying models?
How can I convert these unique keys into model keys for the query?
Can't I use a unique string as key for querying the db when that
string is not assigned to an existing model instance yet?
--~--~-~--~~~---~--~~
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
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: App datastore vs. user datastore
No, of course not. They are in no way related. On Dec 22, 11:39 pm, ussuri peter.oskol...@gmail.com wrote: Hello! Is there a way to store app data in the user's dataspace (those 7gb each user has for gmail, docs, etc.)? This way each user will be responsible for keeping their quotas, and not the app. 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Datastore impossibly slow?
When displaying the data to the user I only show the last 20 records, based on time. I read that the larger the datastore, the slower the response time, so I tried to impliment some system to prune the data. This is only a limitation of the basic datastore implementation in the SDK, not in production. Good thing too, considering all entities for all apps, as well as their indexes, are stored in the same four bigtables. The backend your data sits in, serves and stores many, many millions of entities already. :) If you want to clear out stale data, run a handler that deletes for example 10 entities at a time, then returns whether or not it should be called again, and have your off-site cron call that url until it is done. That is about the best you can do for now, until we get background processing. Hope to help, Thomas --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Announcing: System Status Dashboard, Quota Details Page, and a Preview of Billing
The docs are fine, I was referring to the billing of the other quotas. Or will they rise proportionally to CPU usage, storage and bandwidth? - Thomas On Dec 21, 7:56 pm, Dan Sanderson dansander...@google.com wrote: On Sat, Dec 20, 2008 at 11:06 PM, Thomas Johansson prenc...@gmail.comwrote: Speaking of the billing, perhaps you can elaborate on the other quotas in place, like sending emails, urlfetch and so forth? The best sources of info on the quotas right now are the Quotas section of the Admin Console, and the new section in the documentation: http://code.google.com/appengine/docs/quotas.html The docs have the definitions, and the Console has the precise amounts for your application (the free levels) and how much your app has used in the past 24 hours. Please let me know if you have any further questions after looking at these pages, so we can improve the docs. -- Dan --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Announcing: System Status Dashboard, Quota Details Page, and a Preview of Billing
Speaking of the billing, perhaps you can elaborate on the other quotas in place, like sending emails, urlfetch and so forth? - Thomas On Dec 21, 6:34 am, Dan Sanderson dansander...@google.com wrote: We haven't yet announced information that answers your question directly. If you haven't seen it, check out the billing sneak peak we snuck in to the last blog entry:http://googleappengine.blogspot.com/2008/12/system-status-dashboard-q... Hehe.. I'll take that as a cautious yes then. ;) Speaking of the billing, perhaps you can elaborate on the other quotas in place, like sending emails, urlfetch and so forth? Of course, you'll see the whole thing when we launch the feature, which will be soon. I've long since learned that big corporations use a vastly different definition of 'soon' than the rest of us. ;) Keep up the good work! - Thomas --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: are numeric ids of deleted entities reused?
Forgot to ask; How does the key fit into the hierarchy, compared to the key_name id? On Dec 21, 8:14 am, Thomas Johansson prenc...@gmail.com wrote: Hi ryan, Is this to be interpreted as getting the following, in order, more or less? (where the ID/Key is in square brackets) /Image[42] /Image[127841] /Thread[10]/Post[42] /Thread[10]/Post[127841] E.g. the ID is ever increasing, but only for the current fully qualified path? Can we ever experience inserting a record that will have a lower ID than the previous? Thanks, Thomas On Dec 21, 6:13 am, ryan ryanb+appeng...@google.com wrote: On Dec 20, 7:09 pm, jeremy jeremy.a...@gmail.com wrote: are numeric ids of deleted entities reused? i really hope not. good question. no, they're not. you're probably already on top of this, but just for the record, ids themselves aren't unique across entities. only an entity's full path is guaranteed to be unique. ids and key names are only guaranteed to be unique among entities of the same kind that have the same parent (or that are root entities). more inhttp://code.google.com/appengine/docs/datastore/keysandentitygroups.h... . --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 18 hours of Over Quota, Dashboard and Quota Details indicate everything's fine
Marcia is going to ask for your app id to look into it, so either mail Marcia directly or post it here to speed things up. Having a site offline is never fun. Just out of curiosity, what kind of app is it? On Dec 18, 3:57 pm, Ben Bishop leo...@gmail.com wrote: For the past 18 hours my app has been disabled with an Over Quota 403 error. The Dashboard indicates everything's fine, CPU Time is barely registering. The new Quota Details shows requests under 4%, everything else around 0%, and no High CPU credits have been used. Two and a half hours ago I redeployed to a new app slot to monitor what's going on. It took 15 mins until the Over Quota error. Again, Dashboard, Quota Details and Logs are not showing anything wrong. This app has been running with traffic up until this point for nine days without issue, and since the last deployment four days ago. Anyone have any troubleshooting tips? --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Google Team: Please Make Django 1.0 A Higher Priority
I just want to address one thing here: There is nothing in AppEngine that is tied in any way to django or any framework. They just expose a pure CGI model and service APIs (memcache, datastore and so forth). It is designed with the standard python model in mind; CGI and WSGI. It is included because it is the most popular framework out there, and easy to get started with. Any python framework that talks CGI or WSGI works great on appengine, including their own webapp mini-framework based on webob and django templates. That said, getting django 1.0 in appengine would be nice. I personally don't use it but I can appreciate the complexities of getting it working on your own with the current 1000 file and 1mb size limitations. Even better would be lifting those limitations so you wouldn't have to rely on them keeping it up to date. On Dec 19, 1:54 am, cz czer...@gmail.com wrote: So far, for me App Engine has worked pretty well. The issue regarding Django 1.0 is a little more complicated than just use zipimport and django helper which is the standard response. While this works and is in fact what I use, there are some issues. One is that if your app doesn't have a lot of traffic Django is zipimported on almost every page request and the all monkey patching at init time doesn't seem super fast. This can blow out your CPU quota. The other thing is that the App Engine designers obviously had Django in mind when they designed App Engine and integrated (maybe included is a better word) it in the API. It's not just another feature request from the clamoring masses. I'm skeptical that upgrading to 1.0 would cause as much anguish as Google implies. Most serious users of Django use a zipped up 1.0 and the upgrade would be seamless. For the others, they've had a fair amount of time already to think about the changes and should be ready to make the changes if they haven't already. Also, App Engine is still beta which implies that every app running on it is in beta as well. Current users of those apps should expect some hiccups. I know there are a million other feature requests but this one is a little more of a basic API fix than a feature like adding Java or whatever (why don't the Java people just use one of the many hosted servlet environments anyway?). All in all, I'm pretty excited with App Engine. It was a great excuse to learn Python after programming in Java for many years, and I like the simplicity and basic level of constraints of the environment. Sure I would love a whole bunch more features but I figure they'll arrive eventually. It is a bit disconcerting that developer interest seems to have waned (based on forum traffic). And I wish Google would give us a little more open about what they are working on. I get the feeling that there are maybe three developers working on App Engine in their spare time and Google as a company isn't quite 100% sure they will fully support it. Please tell me I'm wrong. happy programming, - Claude On Dec 18, 1:12 pm, Greg g.fawc...@gmail.com wrote: I can understand the frustration when there seems to be little movement on something that is important to you... --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Efficient paging using __key__ instead of a dedicated unique property
Has anybody taken on the challenge of implementing a library for this? I'd love to see one, but it's too big a task for me to tackle currently. One question springs to mind, however: What about user friendly / readable / hackable urls? How would you go about implementing e.g. ? page=10 or ?offset=42 with the entity bookmarks, in a way that doesn't require a bunch of processing (e.g. fragile) to maintain? ryan: We really *really* need some kind of pagination built-in though, it has to be said. It is more or less the number one constraint for everybody I've talked to, and something we all need in one way or another. The other constraints can be worked around with relative ease, but pagination is smack in your face for even the simplest stuff; And as you clearly demonstrate with the above, not exactly trivial to implement efficiently, not to mention in a scalable manner. Thanks, Thomas --~--~-~--~~~---~--~~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Is there hope that content-encoding will ever be allowed?
I'm not quite sure what is that you are looking for, but appengine is not intended to be used as storage, it is intended for full on applications. With that said, you can freely set any headers you please by writing your own URL handler in Python. On Dec 9, 11:10 am, jago [EMAIL PROTECTED] wrote: Well partially. Obviously I would prefer compressing the file by a factor 10 and then send less data, without setting the right content- encoding this is impossible though. Bigger files would at least not totally invalidate appengine for my use. Still it is no replacement for the content-encoding feature. On Dec 9, 9:59 am, Thomas Johansson [EMAIL PROTECTED] wrote: Hi jago, As per the roadmap (http://code.google.com/appengine/docs/ roadmap.html); Service for storing and serving large files will be coming in the October '08 - March '09 timeline. That should solve your problem, if I'm not mistaken? Personally, I hope that applies to regular old static content and code as well, ideally including lifting the 1.000 file limit, but probably not. On Dec 9, 8:43 am, jago [EMAIL PROTECTED] wrote: I would like to host an applet on appengine. Still either I compress the jars with pack200 which brings the size of each jar well below 1MB but then I have no content-encoding. Or, I don't compess the jars and hit the 1MB filesize limitation. AppEngine really has become frustrating. There are just too many limitations. Will this ever change? --~--~-~--~~~---~--~~ 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: Is there hope that content-encoding will ever be allowed?
On Dec 9, 6:32 pm, jago [EMAIL PROTECTED] wrote: No you can't. You cannot set the content-encoding in the header in appengine. Even if you write your own code. Opening sockets is not allowed just to remind you. I'm not exactly sure what you are talking about here. You are serving the jars for the applet using HTTP, correct? AppEngine does not in *any* way restrict what output you send, other than the size. Content- Encoding is just another header, and you certainly don't need sockets for that. Simply write a python handler that sets the content encoding, opens the file and writes it to the stream (stdout). If you need to serve something that isn't HTTP, you're barking up the wrong tree. --~--~-~--~~~---~--~~ 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: Is there hope that content-encoding will ever be allowed?
Huh. Never seen this before, I do apologise for the confusion. That really should be documented clearly somewhere that isn't specific to one of their libraries, as that seems to be a core limitation. Again, sorry for the confusion. On Dec 9, 8:44 pm, Barry Hunter [EMAIL PROTECTED] wrote: 2008/12/9 Thomas Johansson [EMAIL PROTECTED]: On Dec 9, 6:32 pm, jago [EMAIL PROTECTED] wrote: No you can't. You cannot set the content-encoding in the header in appengine. Even if you write your own code. Opening sockets is not allowed just to remind you. I'm not exactly sure what you are talking about here. You are serving the jars for the applet using HTTP, correct? AppEngine does not in *any* way restrict what output you send, other than the size. Umm, the documentation tends to contradict that! http://code.google.com/appengine/docs/webapp/responseclass.html#Disal... Content- Encoding is just another header, and you certainly don't need sockets for that. Simply write a python handler that sets the content encoding, opens the file and writes it to the stream (stdout). If you need to serve something that isn't HTTP, you're barking up the wrong tree. -- 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: Still having trouble with high-cpu warnings for thumbnails.
At Google IO I believe it was mentioned that TextProperty's are fine for anything that you don't want indexed; They are no less efficient than strings for short data. You might want to look into trying that out with mime and type if you don't filter/order by them. Other than that, I'd suggest trying to memcache the images, something to the effect of: id = int(id) cache_key = 'ImageThumb:%i' % id image = memcache.get(cache_key) if not image: image = ImageThumb.get_by_id(id) if image: memcache.set(cache_key, image, 3600) if image: self.response.headers['Content-Type'] = str(image.mime) self.response.out.write(image.thumb) else: self.error(404) In addition to that, I'd recommend you generate cache headers, in particular etag and expiration. A good idea would be to generate the etag when the ImageThumb is created, and then compare against that from cache, before you write out the image. As an added bonus you could store the etag on it's own in the cache, separate from the image, and only pull out the actual image in case the etags don't match. On Sep 25, 4:59 am, iceanfire [EMAIL PROTECTED] wrote: I'm still having trouble with high-cpu warnings for thumbnails. This time around I took some profiler data to see what's causing it. But before I get into that here is the model i'm using: class ImageThumb(db.Model): binId = db.IntegerProperty() thumb = db.BlobProperty(default=None) building = db.ReferenceProperty(Buildings) apartment = db.ReferenceProperty(Apartments) mime = db.StringProperty() type = db.StringProperty(choices=['Floor Plan','Picture']) created_by = db.UserProperty() So here's the Profiler cpu data: 2538 function calls (2472 primitive calls) in 0.028 CPU seconds (rest of the data:http://docs.google.com/Doc?id=dgfxff5_30hc9tjsgg) But here's the warning: This request used a high amount of CPU, and was roughly 1.3 times over the average request CPU limit. High CPU requests have a small quota, and if you exceed this quota, your app will be temporarily disabled. Here's the megacycle info from the new Admin console: 1339mcycles 7kb Here's the code that pulls up the data for thumbnails: class Apt_thumb (webapp.RequestHandler): def get(self,id): image = ImageThumb.get_by_id(int(id)) if image: self.response.headers['Content-Type'] = str(image.mime) self.response.out.write(image.thumb) else: self.error(404) The images stored are 4kb each in the datastore. As I said, I had this problem earlier, so I had taken out the full image and put that in its own Model. Clearly that didn't help. Any idea what's causing this high-cpu error how I can fix it? 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: Denial of Service Attack on a GAE Application
Marzia - That is great news. Will this also help with genuine traffic spikes? A simple application I use to test, which does a single datastore fetch for 5 items that are a few bytes each, and stores it in memcache for 10 seconds, can go over quota by a simple ab -c 30 -n 1. I've tried with a very gradual ramp up, being very careful not to trigger high cpu spawn warnings, but regardless, after a while, it will just start spewing them all over and the app dies. This is with a constant load after build up, not a spike. I'm hoping you can confirm that said fix will also solve that issue? - Thomas On Sep 24, 6:42 pm, Marzia Niccolai [EMAIL PROTECTED] wrote: Hi, We've identified an issue that can cause an application to hit one of our short-term quotas after a very sudden spike in traffic, which would prevent it from serving for a short time. We're currently working on a fix to address this issue and expect to have it out shortly. On the broader issue of denial-of-service attacks, these are an unfortunate reality in the web world. While we don't currently offer applications any specific protections against attacks of this nature, this is something we're interested in looking into for the future. In the near-term, when we begin allowing developers to purchase computing resources beyond our free limits, we will provide a mechanism for reimbursement in the event of a DOS attack. -Marzia On Mon, Sep 22, 2008 at 3:41 PM, Sharp-Developer.Net [EMAIL PROTECTED] wrote: Starred - I think it's gonna be even more impotant when we get paid service. -- Alex http://sharp-developer.net/ On Sep 20, 5:31 am, Tony Smith [EMAIL PROTECTED] wrote: Hi, I created an issue for this request. Please star it if you feel it's important to you. http://code.google.com/p/googleappengine/issues/detail?id=718 Thanks, Tony --~--~-~--~~~---~--~~ 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: BadRequestError: Salary search with over 500K records
Entities always have a key, available as entity.key(). In addition to
that, you can set a friendly key at construction only (can't be
changed or set later), using key_name. If you do not however set a
key_name, app engine will assign a numeric id, available as
entity.key().id().
In other words, change your pagination to something like: items =
Item.filter('key ', request.get('start')).fetch(1000), and pass the
key of the last item as the start parameter.
On Sep 25, 6:45 am, Venkatesh Rangarajan
[EMAIL PROTECTED] wrote:
Folks,
I have created a salary search application (http://payrate.appspot.com)
I have uploaded around 500K records without an ID Field ( yeah,my Bad).
Now i am running into BadRequestError: offset may not be above 1000 error
when the results exceed 1000 and user is on the last page. I display 100
records per page.
Sample :http://payrate.appspot.com/?keyword=Engineerpage=800
Any ideas on how I can update all the records with Index ? I know I could do
that using page refreshes, but looking for some elegant solution.
Rgds,
Venkatesh
--~--~-~--~~~---~--~~
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: Quota : Bandwidth In/out per Day != Data Sent/Received
The day is chunked into five pieces. Roughly 5 hours per chunk. The idea is that this way, even if you exhaust one 5 hour period, you'll still be able to serve the remaining 19. Of course, the real reason is so when they start charging, this way they'll be able to charge you for spike traffic that wouldn't otherwise exceed your daily free quota. Speaking of quotas, I'm really starting to wonder if there isn't something really wrong about their calculation; I did a load benchmark earlier, a simple ab2 -c 10 over a long period of time, after building up the load. Everything was working great, until suddenly, after about 40k requests, a ton of requests started spewing the dreaded cpu warnings. If I'd started a -c 100 or something then I'd understand it, but this was the exact same load pattern over a long period of time, and shouldn't result in any changes whatsoever on the google side of things. A completely stable workload, but still app engine went funky after a while and starting spewing the warnings that the requests never trigger under normal circumstances. If a completely stable workload like that will cause you to go over quota, there's no chance in hell you'll ever get even close to saturating your alotted 5 hour quotas. (Sorry to derail your thread a little bit.) On Sep 4, 11:31 pm, Sylvain [EMAIL PROTECTED] wrote: There are two kinds of quota. Documentation : Bandwidth In/out per Day = 10 000 MB Dashboard : Data Sent/Received = 2 000 MB Could you explain the difference ? Thank you. --~--~-~--~~~---~--~~ 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: Quota Request
Once they get out of preview, it'll all be automated I'm sure. Going over the free quota will simply incur costs. Hopefully they will have measures in place so you can set a roof for how much you want to spend and so on. They have such for adwords though, so they should have that here as well. With that said, the support has been awfully unresponsive during this preview period, quota issues aside. It certainly doesn't leave a good impression of how they will handle support at launch. Somewhat off-topic: Out of curiosity, how are you actually thumbnailing the sites? I assume you run a seperate box with a cron or something to that effect? And do you happen to know a way to get the image dimensions / metadata using the google images api? - Thomas On Sep 3, 6:37 pm, Paul Kinlan [EMAIL PROTECTED] wrote: I hope they will help me out. It is not a good avertisment for the app engine when the app that is on the Editor Pick list is no longer working. I am willing to pay for the usage, I just wish google were more responsive, if they can't manage the process at this stage then how will they manage when the app engine is no longer in Preview stage. I know that we as developers have to accept that this is Preview Release and as such are restricted to free usage quotas, but we don't seem to hear anything from the guys about anything, especially quota increase requests. Paul. 2008/9/3 vorun [EMAIL PROTECTED] don't hold your breathe for google to help you, i have the same issue and its been months and never heard from from them on this On Sep 3, 1:15 am, Paul Kinlan [EMAIL PROTECTED] wrote: Hi, My app is right on the quota (websnapper -www.thethumbthing.com). I requested a quota increase and received a request for more information which I have supplied. Unfortunately, no one at appengine support has got back to me about the quota increase that I have requested. I am sorry to be posting this publicly on the forum, but as there isn't anyway of tracking support requests I have no idea what is going on. I have had to stop uploading thumbnail images. I am willing to pay for the space that my app is using. Please Google, can you implement a sufficient support process and can you let us know when the pricing policy will come in to effect. Kind regards, Paul Kinlan --~--~-~--~~~---~--~~ 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: Mako Templates for Python
Jinja 2. Similar to django templates but much more powerful and rivals mako in speed. It also has sane, python-like conditionals; No ifnotequal and such sillyness. Important to note that it is however NOT embedded python. http://jinja.pocoo.org/2/ On Sep 3, 9:49 pm, Davide Rognoni [EMAIL PROTECTED] wrote: http://www.makotemplates.org Mako is a template library written in Python. Insanely Fast. An included bench suite, adapted from a suite included with Genshi, has these results for a simple three-sectioned layout: Mako: 1.10 ms Myghty: 4.52 ms Cheetah: 1.10 ms Genshi: 11.46 ms Django: 2.74 ms Kid: 14.54 ms Since a speed test is always a flashpoint for controversy, and you can modify the bench to show different variances, the point here is not that Mako is faster; its not meant as a competitive point. The point is, Mako is as fast as any of the other currently popular approaches. -- Best Template Enginehttp://pyoohtml.appspot.com/best-template-engine --~--~-~--~~~---~--~~ 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: live debugging is horribly implemented
Minor thing, but worth noting you can just do logging.exception('foo')
to log an exception; Don't need to mess with sys yourself.
On Aug 31, 3:14 am, Alexander Kojevnikov [EMAIL PROTECTED]
wrote:
Thank you so much for pointing me towards the logging module.
No worries, I too learned about it just a few days ago :)
Apparently the dev_appserver isn't as sensitive as the
live server, so it was functioning without complaint, and then DOA in live.
Anyhow, I still think that it's very inconvenient that the logs in the
appengine admin view don't display anything for malformed app.yaml.
I suggest adding an issue into the bug tracking system with a sample
app.yaml that reproduces this problem. IMO, the SDK should behave
as close as possible to the live version of GAE. And in any case
such errors should be logged.
Cheers,
Alex
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
