Fwd: Elixir bug

1 view
Skip to first unread message

Jonathan LaCour

unread,
Jan 8, 2008, 12:13:49 PM1/8/08
to sqle...@googlegroups.com
What follows is an email from Ben Bangert regarding an odd bug, that
appears to be a race condition. I am in meetings for the next couple
of days, so I won't have a chance to look at this before then. If
anyone else could help me out by taking a look, it would be great!

Gaetan -- you might have some insight here. It looks to me like
something is happening inside setup_all() before the classes have all
had time to fully load.

--
Jonathan LaCour
http://cleverdevil.org


Begin forwarded message:

> From: Ben Bangert <b...@groovie.org>
> Date: January 8, 2008 1:29:39 AM EST
> To: Jonathan LaCour <jona...@cleverdevil.org>
> Subject: Elixir bug
>
> Ok, I made a small directory of some base models. On my mac, and my
> linux box, the first 'python __init__.py' pops up an exception,
> later runs are fine. Removing the .pyc causes it to occur again.
> Interesting note, this does NOT happen with python2.4, just Python
> 2.5. No idea....
>
> Taking it another step, make a new Pylons project with pylons-dev,
> use sqlalchemy options, wipe the model dir, and copy this dir in as
> model instead. paster shell will *always* throw the exception.
> There's definitely some sort of race condition going on, playing
> with the models, which ones __init__ loads, etc. seems to change the
> behavior in totally random ways as well.
>
> Enjoy!
>

elixir_bug.tbz

Gaetan de Menten

unread,
Jan 8, 2008, 1:13:47 PM1/8/08
to sqle...@googlegroups.com
On Jan 8, 2008 6:13 PM, Jonathan LaCour <jonatha...@cleverdevil.org> wrote:
> What follows is an email from Ben Bangert regarding an odd bug, that
> appears to be a race condition. I am in meetings for the next couple
> of days, so I won't have a chance to look at this before then. If
> anyone else could help me out by taking a look, it would be great!
>
> Gaetan -- you might have some insight here. It looks to me like
> something is happening inside setup_all() before the classes have all
> had time to fully load.

Here I get a traceback ending with:
File "/home/ged/devel/elixir/trunk/elixir/relationships.py", line
427, in target
self._target = caller_entities[classname]
KeyError: 'Party'

My initial impression is that this problem is caused by a pattern for
specifying relationships target that I didn't think of at the time
(even though it looks pretty natural now that I see it).

The two ways which are currently supported are:
- full path addressing (including module the name in all targets)
eg. parties = OneToMany('party.Party')
- local (in the frame where the "source" entity is defined) references:
eg. (in datafolder.py)

from party import Party

class DataFolder(Entity):
...
parties = OneToMany('Party')

Now, why it works in python2.4, I honestly don't know.

FWIW, improving the "target" resolving code is ticket #9
(http://elixir.ematia.de/trac/ticket/9). I'll add a note to the ticket
to make sure I try to get Ben's way of doing things to work when I
tackle that ticket.

> Begin forwarded message:
>
> > From: Ben Bangert <b...@groovie.org>
> > Date: January 8, 2008 1:29:39 AM EST
> > To: Jonathan LaCour <jona...@cleverdevil.org>
> > Subject: Elixir bug
> >
> > Ok, I made a small directory of some base models. On my mac, and my
> > linux box, the first 'python __init__.py' pops up an exception,
> > later runs are fine. Removing the .pyc causes it to occur again.
> > Interesting note, this does NOT happen with python2.4, just Python
> > 2.5. No idea....
> >
> > Taking it another step, make a new Pylons project with pylons-dev,
> > use sqlalchemy options, wipe the model dir, and copy this dir in as
> > model instead. paster shell will *always* throw the exception.
> > There's definitely some sort of race condition going on, playing
> > with the models, which ones __init__ loads, etc. seems to change the
> > behavior in totally random ways as well.
> >
> > Enjoy!

--
Gaëtan de Menten
http://openhex.org

Ben Bangert

unread,
Jan 8, 2008, 1:51:26 PM1/8/08
to SQLElixir
On Jan 8, 10:13 am, "Gaetan de Menten" <gdemen...@gmail.com> wrote:
> The two ways which are currently supported are:
> - full path addressing (including module the name in all targets)
>      eg. parties = OneToMany('party.Party')

This works, though its rather verbose, since this is in another
project the full path is more like, 'myproj.model.party.Party'. Rather
verbose, but at least it works!

> - local (in the frame where the "source" entity is defined) references:
>      eg. (in datafolder.py)
>
>      from party import Party
>
>      class DataFolder(Entity):
>          ...
>          parties = OneToMany('Party')

If you look at some of the modules, I don't believe I can do this
since several of them have circular references, which I believe would
likely cause circular import issues.


> > FWIW, improving the "target" resolving code is ticket #9
> (http://elixir.ematia.de/trac/ticket/9). I'll add a note to the ticket
> to make sure I try to get Ben's way of doing things to work when I
> tackle that ticket.

Awesome, maybe if Elixir kept a record of model names, and only
required the full module name in a case where there was duplicate
Elixir Entities.

Thanks for the pointer, after switching to the long module name
version, it does work.

Cheers,
Ben
Reply all
Reply to author
Forward
0 new messages