Hello list,
I don't know exactly how to report 2 related "overlap" problems I've
recently encountered, and maybe it's not even the right list to report
them. But even then, it's relevant to Pyramid.
These problems started to appear when I created a second Pyramid project
under an existing virtualenv. The two Pyramid projects are called "foo"
and "bar". Each or them uses SQLAlchemy table inheritance, on two
distinct PostgreSQL databases, i.e. :
- A common e-commerce module provides a base class "Article", attached
to a table. This represents a generic article in the catalogue.
- The "foo" module provides a class "FooArticle", which inherits from
"Article". This creates to 2 linked tables, "article" and
"foo_article", in Pg database "foo".
- Similarly, the "bar" module provides a class "BarArticle" which also
inherits from "Article". This creates 2 tables, "article" and
"bar_article", in Pg database "bar".
- To make code more legible, the two classes "FooArticle" and
"BarArticle" are always used under the alias "Article" in their
respective projects (the parent class "Article" is never used directly),
i.e.:
from foo.models import FooArticle as Article
or:
from bar.models import BarArticle as Article
=====
Overlap #1: SQLAlchemy maps the wrong class to the returned data :
I assume this is because the classes bear the same names (or aliases) in
the two distinct projects :
$ cd foo
$ pshell development.ini
In [1]: from foo.models import *
In [2]: Article
Out[2]: foo.models.article.FooArticle
In [3]: print Session.query(Article)
SELECT [...]
FROM article JOIN foo_article ON article.id = foo_article.id
In [4]: a = Session.query(Article).first()
In [5]: a
Out[5]: <BarArticle id=19844>
In that example, "Article" is an alias of "FooArticle", which is
confirmed by [2]. The generated SQL query interrogates the right tables,
as shown by [3]. But the object returned by [4] should be an instance of
FooArticle, not BarArticle [5]!
=====
Overlap #2: Supervisord picks the wrong gunicorn_paster script
It happens even when the two projects are moved to separate virtualenvs.
I've been obliged to replace it with daemontools, temporarily or
permanently.
For instance, with the line below:
command = /projects/venv2/bin/gunicorn -w 4 --paste
/projects/venv2/bar/bar/production.ini
supervisord incorrectly launches /projects/venv1/bin/gunicorn...
This is totally illogical... :(
Laurent.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
