Aral Balkan

I've just tagged Gaebar Beta 3 (version 0.3) in GitHub.

This is a bugfix release, with changes almost entirely submitted by or suggested by the community.

Thanks go to gumptionthomas, Martin Kleppmann, Tony Andrews, Rafal Jonca, and, of course, Guido van Rossum, for your patches and feedback.

Changes in Beta 3

• Merged gumptionthomas's pull request (commit)
  • Fixed unicode and escape string issues with key_names
  • Properly reference InternalError as db.InternalError
• Applied patch by Martin Kleppmann (commit)
• Backup doesn't blow up when there are non-backup files/folders in the backups folder. (e.g., if your project uses SVN)
• Updated the readme.txt based on Guido's feedback (commit)
• Added note to readme.txt regarding getting more detailed exceptions (thanks to Tony Andrews; commit).
• Applied patch by Rafal Jonca (commit):
  • Key names may now contain unicode
  • ReferenceProperties can now be created with keys of parents, not just model instances
  • Now using global datastore's delete, put, and get methods instead of model's

See the original announcement for a screencast and general information on Gaebar.

Please do keep your feedback coming and, of course, if you have pull requests, patches, or suggestions, please send them my way (and thank you!)

Comments

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

  by Thomas Bohmbach, Jr. on 2009-01-26 20:32:29

• 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.

  by Guria on 2009-04-05 13:00:44

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

  by Patrick H. Lauke on 2009-01-21 14:50:08

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

  by Paul on 2009-01-21 14:56:22

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

  by Aral on 2009-01-21 16:14:34

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

  by Chris on 2009-03-29 22:44:49

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

  by Ara Pehlivanian on 2009-01-22 01:30:48

• 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

  by Alexander Vasiljev on 2009-03-26 13:40:04

• 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

  by John on 2009-02-04 02:46:21

• I noticed recently that parent/child relationships aren't being restored properly. Is that a known issue? Thanks, Tony

  by Tony Andrews on 2009-02-23 18:48:28

• 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

  by Alexander Vasiljev on 2009-03-28 11:48:42

• 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

  by Chris on 2009-03-29 22:34:12

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

  by Oyunlar on 2010-02-20 15:21:02