[google-appengine] Re: When is GAE going to support Django 1.0?
Hi Damien, Damien Hou wrote: > To name one, the use of newforms is deprecated in favor of simply forms, > and in the latest beta releases newforms have been removed. I'm using a > django 1.0 alpha version with one of my apps and I see django raising > errors about GAE code still using the deprecated newforms. > > I haven't tried 1.0 beta on GAE yet. But plan to try the 1.0 final code > and see if there's any compatibility problems. But the best thing would > be that GAE by default supports the 1.0 final release and upgrade from > the current outdated 0.96 release You'll need to use the latest SVN head revision of the helper if you are testing Django 1.0. We are actively watching its release progress and updating the helper accordingly as fast as possible. I've just committed (in r58) a patch from issue #78 which fixes the latest round of bugs introduced from the release of beta 2 so the current SVN head should work fine with Django 1.0beta2. There are still some test failures being printed, as the django.contrib.auth application tests are being run when they are not valid for the App Engine Helper environment. I attempted to disable these tests in r51, but the beta2 has re-enabled them somehow. I'll take another look at getting these disabled correctly later tonight. For now you can either ignore them (the only affect you if you run manage.py test) or you can remove django.contrib.auth from your INSTALLED_APPS list if you are not using it. Cheers Matt --~--~-~--~~~---~--~~ 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: Launcher and django-helper using different datastores
Hi Jason, Jason K wrote: > Any idea how to fix this? It's not the end of the world, but I do like > the convenience of using the launcher, and also find it useful to drop > into the manage.py shell. Doesn't help much if they use different > datastore's.. The Django helper does this to allow you to develop multiple Django projects in parallel. The SDK uses the same datastore location for every project, while the Django helper inserts the name of your project into the datastore filename. You can use the --datastore_path and --history_path options to dev_appserver to point it to the locations used by the Django helper rather than the defaults. Having said that, the aim was for you to be able to use manage.py for almost everything when developing a Django project rather than having to use a combination of manage.py and dev_appserver. From what you have described you should be able to use a combination of manage.py runserver and manage.py shell and the helper will handle pointing you to the appropriate datastore in the background. Cheers Matt --~--~-~--~~~---~--~~ 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: Google app engine django helper, manage.py update, and (1,0,'final')
Aral Balkan wrote: > Can someone respond as to the roadmap for Django 1.0 compatibility? The currently released version of the helper (r52) supports Django 0.96 and the early Django 1.0 alpha versions. Support for Django 1.0 final is present in the HEAD (r60) of the helper. I'd like to add support for loading Django 1.0 from a zipfile via the zipimport functionality in version 1.1.3 of the SDK before making a new release of the helper with Django 1.0 support. In the meantime you should be able to use the helper and Django 1.0 together by checking out the helper directly from svn. Cheers --~--~-~--~~~---~--~~ 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: Need help with Appengine helper.
Peter wrote: > Hmm. A couple of extra lines of documentation would have been very > helpful. I'm not used to ignoring warnings and errors. I've committed a change to the Google Appengine Helper for Django article to mention these warnings and that they can be safely ignored. > The datastore seems to be empty at each startup which could be a bit > tedious. Is there any way to keep it between server starts? The default path for the datastore is in /tmp which on some distributions is cleared on reboot. You can run dev_appserver.py manually and specify the --datastore_path and --history_path options to put it somewhere else. Cheers --~--~-~--~~~---~--~~ 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: TemplateSyntaxError when using app engine helper's auth on appspot
Hi Bobby, Bobby Moretti wrote: > This seems to do the trick, but it shouldn't be necessary. Any idea > what I've been doing wrong? I presume that you're using Django 1.0? Anyway, this looks to be Django 1.0 related breakage to me. I've committed a fix in r62 that makes the login/logout URL template tags available to all templates by default. Cheers --~--~-~--~~~---~--~~ 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 field key_name in djangoforms
Denya wrote: > Thank you for idea about initial! > > code starting at line 803 in google.appengine.ext.db.djangoforms is from > save() method. > 'continue' statement there means that if you are editing data and > key_name passed, form processor must not try to change key_name in db, > 'cause it's impossible :) The code on line 803 is correct, at update time within the form class the key_name must be ignored. > So, my question -- is it right behaviour? Or may be developers forget, > that the need to fill field by real data from db?... Before the Form object can be created to process an update, you first have to fetch an instance of the existing object from the datastore. You need the key_name at this point. If you look at the article describing how to use Django forms (http://code.google.com/appengine/articles/djangoforms.html), although it doesn't cover the key_name case specifically, the corresponding case when using an id passes the id as a hidden form parameter, the same approach could/should? be used with the key_name. Having said that, it seems like a pretty simple fix to initialise the key_name field when the instance is passed to the form object and it I agree from the conversation you've just had that it seems like the expected behaviour. I cannot recall if there was a specific reason why this wasn't done when the key_name functionality was added. Maybe it was forgotten as you suggest. In any case I've attached a patch that I believe will fix the issue, it is basically using the initial hack Jeseja identified but within the Form initialiser code. I haven't tested it thoroughly so use at your own risk. If it does turn out to fix the issue you are seeing it would be good if you could open a new issue in the tracker, then let me know the issue number and I'll see what I can do about getting this fixed in the next SDK release. Cheers Matt --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- --- djangoforms.py.orig 2008-11-26 18:33:03.067712000 + +++ djangoforms.py 2008-11-26 18:31:43.51135 + @@ -751,6 +751,8 @@ if opts.exclude and name in opts.exclude: continue object_data[name] = prop.get_value_for_form(instance) + if "key_name" in self.base_fields: +object_data["key_name"] = instance.key().name() if initial is not None: object_data.update(initial) kwargs = dict(data=data, files=files, auto_id=auto_id,
[google-appengine] Re: Problem with models & Google App Engine Helper for Django
Hi Carlin, Carlin Wiegner wrote: > Right now my models.py is in the root directory of "mysite". As I believe Ian was hinting at in his response, the helper (and Django) expect your models to be within a Django application (basically a subfolder) of your Django project (your Django project == your App Engine application, confusing I know ;p). So you need to create a directory, say called "myapp" and place your models.py in that (don't forget to also add __init__.py). Then you list "myapp" in the INSTALLED_APPS section of settings.py and you should be good to go. Cheers Matt Brown --~--~-~--~~~---~--~~ 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: SDK 1.1.9 breaks google-app-engine-django?
Hi Michael, mcobrien wrote: > now that sdk 1.1.9 disallows access to "skipped" files, the > LoadAppengineEnvironment() function in the django helper isn't > working. It makes a call to LoadAppConfig, which tries to read > app.yaml. Since this is a skipped file (it's actually marked as > skipped when LoadAppConfig is first called), the read fails. > > Is anyone else having this issue, or is something strange about my > config? I'm using the latest google-app-engine-django from svn, and > Vista x64. Yes, this was a problem. I've just committed r72 and r73 to make the helper compatible with the new SDK release. Please let us know (file an issue in the tracker) if you encounter any more instances of the helper attempting to access files that would not be present in a production environment. Cheers Matt Brown --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
