[Grok-dev] spotlight on: megrok.traject

Ethan Jucovy ejucovy at gmail.com
Sun Jan 24 10:48:19 EST 2010


Hey Martijn,

On Mon, Jan 18, 2010 at 4:21 PM, Martijn Faassen <faassen at startifact.com>
wrote:
>> [Django + Grok = Grongo]
>
> Alternatively just a buildout with a Django-Grok would be interesting to
> see - we could put it up in grok.zope.org/grokapps or something. We must
> record this for anyone coming along in the future who wants to mess
> around with this.

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:

1) Add Django and megrok.traject dependencies

2) Generate an additional script, bin/djangoctl, which delegates to Django's
django-admin.py

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.

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.  :)

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)

> I am wondering how this deals with transactions. With zope.sqlalchemy we
> integrate Zope's transaction machinery into SQLAlchemy. I would expect
> something similar would need to happen here to ensure that data is
> properly committed.

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.

Cheers,
Ethan

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? :)

[1] http://docs.djangoproject.com/en/dev/topics/db/transactions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20100124/d5e14011/attachment-0001.html 


More information about the Grok-dev mailing list