Gaebar Beta 3 (version 0.3) released

13 Comments »

1. 

   i assume, by the pink colour, the fact that it sounds like “gay bar” is intentional, yes?

   Patrick H. Lauke
2. 

   Well the company is in Brighton, need I say more ;-)

   Paul
3. 

   What? It’s *pink?* Darn my color-blind eyes! And it sounds like “gay bar?” My aphasia be cursed! :P

   Aral
4. 

   Hehehehe, Patrick, you beat me to it! :-)

   Ara Pehlivanian
5. 

   Hi Aral. Grats on 0.3, unfortunately I have to re-report a bug that my patch fixed but was commented out by Rafal Jonca’s patch. Specifically, if you have a key_name that ends in an odd number of ‘\’ characters, the code shard created by Gaebar that creates that entity will be invalid (have a non-terminated string).

   (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?

   Thomas Bohmbach, Jr.
6. 

   Hi Aral,

   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

   John
7. 

   I noticed recently that parent/child relationships aren’t being restored properly. Is that a known issue?

   Thanks,
   Tony

   Tony Andrews
8. 

   Hello, John.

   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

   Alexander Vasiljev
9. 

   Believe it or not, I made PolyModel works in gaebar. Details here:
   http://groups.google.com/group/app-engine-patch/browse_thread/thread/441ad1a7a47cf59b/f0007e42a53924a9#f0007e42a53924a9

   Alexander Vasiljev
10. 

    Gaebar isn’t working for me. When I try and restore a backup, I get the error:

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

    Chris
11. 

    And yes, I did apply Vasiljev’s patch. Unfortunately, it doesn’t appear to work.

    Chris
12. 

    Hi, first of all, thaks for great app.
    In your GitHub projects, such as gaebar-gaed and gaebar-aep you use submodule feature of git to include gaebar and unit tests. You use your personal GitHub urls like git@github.com:aral/gaebar.git, but you should use the public ones, e.g. git://github.com/aral/gaebar.git. For you, of course, works both methods, but for others ‘git submodule init && git submodule update’ process fails because thats needs authentication on GitHub with your account.

    Guria
13. 

    Well the company is in Brighton, need I say more ;-)

    Oyunlar