existing_entity = main_user.get(datastore_types.Key.from_path(‘main_user’, 13094L, _app=app_name))
NameError: global name ‘main_user’ is not defined

The following quick and dirty hack makes gaebar work with aep 1 (DJANGO_STYLE_MODEL_KIND = True):

First, consider you have
yourapp.models.YourModel
then insert yourapp_YourModel entry into settings.GAEBAR_MODELS

After that, patch gaebar/views.py:

— gaebar/views.py 2009-03-26 19:19:00.000000000 +0600
+++ ../local/gaebar/views.py 2009-03-26 18:41:52.000000000 +0600
@@ -448,7 +448,7 @@
for model_name in kind_map:
model_classes.append(kind_map[model_name])

- Model = kind_map[current_model]
+ Model = kind_map[current_model.lower()]

fields = Model.fields()

@@ -548,7 +548,7 @@

# Generate code: Check if entity already exists and delete it if it
# does, by bypassing standard delete logic, because it may be overridden.
- code += u’\texisting_entity = %s.get(%s)\n’ % (current_model, key_repr)
+ code += u’\texisting_entity = %s.get(%s)\n’ % (current_model.split(u’_')[1], key_repr)
code += u’\tif existing_entity:\n’
#code += u’\t\texisting_entity.delete()\n’
code += u’\t\t_delete(existing_entity)\n’
@@ -693,7 +693,7 @@

# OK, all properties are ready, write out the row’s constructor to create the row.
# code += u’\t%s = %s(key_name=%s%s%s%s)\n’ % (row_name, current_model, key_name.__repr__(), properties_code, reference_fields_code, parent_code)
- code += u’\t%s = %s(key_name=u”%s”%s%s%s)\n’ % (row_name, current_model, key_name, properties_code, reference_fields_code, parent_code)
+ code += u’\t%s = %s(key_name=u”%s”%s%s%s)\n’ % (row_name, current_model.split(u’_')[1], key_name, properties_code, reference_fields_code, parent_code)

# Does this row belong to an Expando model? (It’s OK to put Expoando properties after the
# constructor as they cannot be required.)

Yes, there should be
if settings.DJANGO_STYLE_MODEL_KIND…
around and such, but I am too lazy for that

Thanks,
Tony

Thanks for your great work. I couldn’t imagine deploying a GAE app without Gaebar.

While building a site using app-engine-patch from the repository and having difficulty configuring backups, I discovered the following in the aep docs:

“”"
Starting with app-engine-patch 1.0 the model kind() gets prefixed with the app label of the app which defines that model. For example, if you have myapp.models.MyModel the datastore will store entities with the following entity name: myapp_MyModel. This is needed to prevent conflicts when multiple apps define models with the same name. Note that Django uses this naming scheme, too, when creating SQL tables. If necessary, you can disable that feature in your settings.py:

DJANGO_STYLE_MODEL_KIND = False
“”"

How involved would it be to have Gaebar honor the DJANGO_STYLE_MODEL_KIND setting?

Thanks!
-John

(If you’re interested, the reason we have such key_names is due to some automated security audits that were run against our site.)

My solution to this was to use __repr__() on the key_name just like you do for class parameters. This solved not only the non-terminated string case, but also solved (for us anyway) the unicode key_name problem, all without having to change the character encoding of the code shard to utf-8 (which, it seems to me, won’t work if your key_names contain non-utf8 data).

The line in question is in views.py. My patch is the commented out line #695, and Rafal’s line is #696.

It is my belief that Rafal’s unicode key_name fix is unnecessary if we use __repr__() on the key_name, plus it addresses at the same time the non-terminated string bug.

Thoughts?