Hey Martijn,<br><br>On Mon, Jan 18, 2010 at 4:21 PM, Martijn Faassen <<a href="mailto:faassen@startifact.com">faassen@startifact.com</a>> wrote:<br>>> [Django + Grok = Grongo]<br>><br>> Alternatively just a buildout with a Django-Grok would be interesting to<br>
> see - we could put it up in <a href="http://grok.zope.org/grokapps">grok.zope.org/grokapps</a> or something. We must<br>> record this for anyone coming along in the future who wants to mess<br>> around with this.<br>
<br>I'd really like to get a working buildout for this. It'll definitely make it easier for me to experiment further. After trying out a few things, I think I just need to extend the buildout that grokproject generates, in three ways:<br>
<br>1) Add Django and megrok.traject dependencies<br><br>2) Generate an additional script, bin/djangoctl, which delegates to Django's django-admin.py<br>
<br>3) Add the line `os.environ['DJANGO_SETTINGS_MODULE'] = ${something_from_buildout}` to bin/myproject-ctl, bin/paster, etc. I think this is the most straightforward and correct place to put that line, if it's not too difficult to modify buildout's script templates.<br>
<br>Task #3 is the one I'm least confident about. I haven't found any
obvious way to do this. I'd be very grateful if somebody with more
buildout knowledge could point me in the right direction, or tell me
I'm approaching this wrong and give me a different direction. :)<br>
<br>With a buildout in hand I'll be better able to translate things into useful
documentation -- which I'll happily send along to be posted. Then I'll also start playing around with paste.script templates for the various bits & pieces (e.g. Django settings, models, admin, forms, traject views)<br>
<br>> I am wondering how this deals with transactions. With zope.sqlalchemy we<br>> integrate Zope's transaction machinery into SQLAlchemy. I would expect<br>> something similar would need to happen here to ensure that data is<br>
> properly committed.<br><br>Good question .. I have no idea. I know Django has its own middleware-style transaction manager that's on by default when you're using Django's views system and HTTP layer[1]. Grongo would be going underneath that layer so I think things are different. When I get a chance I'll try to take a look at Django's transaction-middleware and the zope.sqlalchemy code, it sounds like between the two of them it shouldn't be hard to get this working properly.<br>
<br>Cheers,<br>Ethan<br><br>P.S. I love the name Grongo. Definitely a friendly dinosaur -- works with Grok to hunt down large mammals and forage berries from the tall trees? :)<br><br>[1] <a href="http://docs.djangoproject.com/en/dev/topics/db/transactions/">http://docs.djangoproject.com/en/dev/topics/db/transactions/</a><br>