Cezary Biele | 2 Jun 23:13 2009
Picon

authkit usersfromdatabase does not create tables

Hi,
I try to learn pylons, and I'm creating small site, reading the pylons book, and trying to use simplesite as a basis.
I've encountered one problem when I tried to set up authkit with users from database.
I add all the imports and users = UsersFromDatabase(model) to websetup.py, but when I run paster setup-app development.ini, user, roles and other necessary tables are not created, and of course it leads to errors a moment after when the script tries to add users and roles:

22:51:33,396 INFO  [sqlalchemy.engine.base.Engine.0x...4f2c] SELECT roles.uid AS roles_uid, roles.name AS roles_name
FROM roles
WHERE roles.name = ?

causes:

sqlalchemy.exc.OperationalError: (OperationalError) no such table: roles u'SELECT roles.uid AS roles_uid, roles.name AS roles_name \nFROM roles \nWHERE roles.name = ? \n LIMIT 1 OFFSET 0' ['delete']

i'd be grateful for any suggestions
thanks in advance
c




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to pylons-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

durumdara | 3 Jun 09:48 2009
Picon

Translating error messages


Hi!

I wanna make a new error document. I found Error Controller, when I
modify it, I can change the style, page format, etc...

But I'm not sure which error messages I can get, and in which format.
Ok, I see that httpexception.py containing the error codes, titles,
messages, but I don't know, that all of parameters are reachable for
me to construct same (but hungarian) messages in the error controller?

Or Pylons have an easier way to I translate error messages and page
style without reconstruct all possible error messages?

Thanks for your help:
   dd
durumdara | 3 Jun 12:01 2009
Picon

Re: Translating error messages


And I found some interesting thing in the error page:

    <div id="container">
        <html>
 <head>
  <title>404 Not Found</title>
 </head>
 <body>
  <h1>404 Not Found</h1>
  The resource could not be found.<br /><br />
 </body>
</html>
    </div>
</body>
</html>

It have two html tags, one for main html, one for the subhtml...
Interesting question: how can I get the error infos from Pylons
objects without cutting/splitting inner html. Have this repr object a
member of method that return same infos?

Thanks for your help:
  dd
Jonathan Vanasco | 3 Jun 22:11 2009

Re: Sharing Projects.


In terms of 'sharing':

I keep a common library of items / frameworks as a unique namespace,
managed in it's own subversion repository; and I tag releases of each
app to their corresponding third party.

I use svn:externals to place the third party stuff into myapp/lib/
externals folders

most of the time, I can use this stuff as is, or just create new
classes in myapp/lib that inherit form the externals

sometimes I need my external stuff to subclass myapp.  it's too hard
to explain how I do that without showing code, and that would bore ,
frighten, or enrage you ( and make me look like an crazy man for
certain things in there ).  but if you need to know how to do that,
let me know.
Wyatt Baldwin | 4 Jun 05:02 2009
Picon

Re: Using config: uris more intelligently


On May 28, 6:08 pm, kochhar <kochhar...@...> wrote:
> Hi all,
>
> I have two .ini files for my app a developmemt.ini and a local.ini which
> overrides some settings in the dev config to use resources local to my machine.
> The relevant parts of my app config files are
>
> --- development.ini
> [pipeline:main]
> pipeline = rev-proxy-prefix
>             some-other-filter
>             mainapp
>
> [filter:rev-proxy-prefix]
> use = egg:PasteDeploy#prefix
> prefix = /race
>
> [filter:some-other-filter]
> use = egg:race#some_entry_point
> config_value = true
>
> [app:mainapp]
> use = egg:race
> full_stack = true
> cache_dir = %(here)s/data
> beaker.session.key = rase
> beaker.session.secret = somesecret
> db.host = dbhost01.example.com
> db.port = 5072
>
> --- local.ini
> [pipeline:main]
> pipeline = rev-proxy-prefix
>             some-other-filter
>             mainapp
>
> [filter:rev-proxy-prefix]
> use = egg:PasteDeploy#prefix
> prefix = /race
>
> [filter:some-other-filter]
> use = egg:race#some_entry_point
> config_value = true
>
> [app:mainapp]
> use = config:development.ini#mainapp
> db.host = localhost
>
> This gives me what I want, my local mainapp overrides the development mainapps
> db.host config. However, the local file is pretty verbose and I have to manually
> keep the pipeline and filter sections in sync with the development file.
> Cumbersome and error prone. In an ideal world I'd like my local.ini to be
>
> [pipeline:main]
> pipeline = config:development.ini
>
> [app:mainapp]
> use = config:development.ini#mainapp
> db.host = localhost
>
> I've tried this syntax with no luck. Paste simply uses the entire config from
> development.ini. Maybe I'm missing something. Is this at all possible with paste
> deploy? If I can't get the pipeline config from the development file, is it
> possible to reference filters in other config files?

You can do something like `pipeline = config:base.ini#filter-section
mainapp`.

I think what you have here doesn't do what you want because it's
equivalent to `pipeline = config:development.ini#main`, which doesn't
make sense because the `pipeline = x y z` list is expected to contain
apps, and a pipeline section isn't an app.

Also, I found that with a pipeline, if the last app listed uses the
config:x.ini syntax, the __file__ attribute of the parsed config is
that *other* file, which I thought was strange.
Wyatt Baldwin | 4 Jun 05:29 2009
Picon

Re: Using config: uris more intelligently


On Jun 3, 8:02 pm, Wyatt Baldwin <wyatt.lee.bald...@...> wrote:
> On May 28, 6:08 pm, kochhar <kochhar...@...> wrote:
>
>
>
> > Hi all,
>
> > I have two .ini files for my app a developmemt.ini and a local.ini which
> > overrides some settings in the dev config to use resources local to my machine.
> > The relevant parts of my app config files are
>
> > --- development.ini
> > [pipeline:main]
> > pipeline = rev-proxy-prefix
> >             some-other-filter
> >             mainapp
>
> > [filter:rev-proxy-prefix]
> > use = egg:PasteDeploy#prefix
> > prefix = /race
> Also, two special section types exist to apply filters to your applications: [filter-app:...] and
[pipeline:...]. Both of these sections define applications, and so can be used wherever an application
is needed.
> > [filter:some-other-filter]
> > use = egg:race#some_entry_point
> > config_value = true
>
> > [app:mainapp]
> > use = egg:race
> > full_stack = true
> > cache_dir = %(here)s/data
> > beaker.session.key = rase
> > beaker.session.secret = somesecret
> > db.host = dbhost01.example.com
> > db.port = 5072
>
> > --- local.ini
> > [pipeline:main]
> > pipeline = rev-proxy-prefix
> >             some-other-filter
> >             mainapp
>
> > [filter:rev-proxy-prefix]
> > use = egg:PasteDeploy#prefix
> > prefix = /race
>
> > [filter:some-other-filter]
> > use = egg:race#some_entry_point
> > config_value = true
>
> > [app:mainapp]
> > use = config:development.ini#mainapp
> > db.host = localhost
>
> > This gives me what I want, my local mainapp overrides the development mainapps
> > db.host config. However, the local file is pretty verbose and I have to manually
> > keep the pipeline and filter sections in sync with the development file.
> > Cumbersome and error prone. In an ideal world I'd like my local.ini to be
>
> > [pipeline:main]
> > pipeline = config:development.ini
>
> > [app:mainapp]
> > use = config:development.ini#mainapp
> > db.host = localhost
>
> > I've tried this syntax with no luck. Paste simply uses the entire config from
> > development.ini. Maybe I'm missing something. Is this at all possible with paste
> > deploy? If I can't get the pipeline config from the development file, is it
> > possible to reference filters in other config files?
>
> You can do something like `pipeline = config:base.ini#filter-section
> mainapp`.
>
> I think what you have here doesn't do what you want because it's
> equivalent to `pipeline = config:development.ini#main`, which doesn't
> make sense because the `pipeline = x y z` list is expected to contain
> apps, and a pipeline section isn't an app.

Well, this isn't true. From the PasteDeploy docs:

    Also, two special section types exist to apply filters to your
    applications: [filter-app:...] and [pipeline:...]. Both of these
    sections define applications, and so can be used wherever
    an application is needed.

> Also, I found that with a pipeline, if the last app listed uses the
> config:x.ini syntax, the __file__ attribute of the parsed config is
> that *other* file, which I thought was strange.
Wyatt Baldwin | 4 Jun 07:33 2009
Picon

Access to "root" WSGI application


I want to get access to the "root" WSGI middleware, the one that is
hit first when a request is made. In this example:

    [pipeline:main]
    pipeline = somefilter auth urlmap

...I want access to `somefilter`. I couldn't find a reference to the
root app anywhere in the environ. Does anyone know how to access this?
For now, I created a wrapper app that saves a reference to itself in
the environ.
Gustavo Narea | 4 Jun 11:54 2009
X-Face
Picon

Re: Access to "root" WSGI application


Hi, Wyatt.

Wyatt said:
> I want to get access to the "root" WSGI middleware, the one that is
> hit first when a request is made. In this example:
>
>     [pipeline:main]
>     pipeline = somefilter auth urlmap
>
> ...I want access to `somefilter`. I couldn't find a reference to the
> root app anywhere in the environ. Does anyone know how to access this?

You can't, because it works like this:
"""
class Middleware1(object):
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        return self.app(environ, start_response)

class Middleware2(object):
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        return self.app(environ, start_response)

class Middleware3(object):
    foo = "some value"
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        return self.app(environ, start_response)

pylonsapp = make_app(...)
pylonsapp = Middleware1(pylonsapp)
pylonsapp = Middleware2(pylonsapp)
pylonsapp = Middleware3(pylonsapp)
"""

So in Middleware1, for example, you cannot access Middleware3 and vice versa. 

> For now, I created a wrapper app that saves a reference to itself in
> the environ.

If you really want it, the standard way to do it is to put in the environ 
whatever you need from that middleware, not the whole middleware.

For example, if what you need is the "foo" argument of Middleware3 in 
Middleware1, you can use this:
"""
class Middleware1(object):
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        if "middleware3.foo" in environ:
            # here it is!
        return self.app(environ, start_response)

class Middleware2(object):
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        return self.app(environ, start_response)

class Middleware3(object):
    foo = "some value"
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # ... do something ...
        environ["middleware3.foo"] = self.foo
        return self.app(environ, start_response)

pylonsapp = make_app(...)
pylonsapp = Middleware1(pylonsapp)
pylonsapp = Middleware2(pylonsapp)
pylonsapp = Middleware3(pylonsapp)
"""

Then this value will be available in any middleware* and the application 
itself.

HTH,

PS: Not exactly "any middleware"; it will be available for any middleware 
under it... So if we had a fourth middleware, it wouldn't be able to access 
environ["middleware3.foo"].
--

-- 
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

Cezary Biele | 4 Jun 12:49 2009
Picon

Re: authkit usersfromdatabase does not create tables

I've just installed SimpleSite demo and setup-app created the tables
flawlessly.
So certainly the problem is with my site, not authkit ;)
I'll try to compare my code with SimpleSite to find out what could cause a
problem.
wish me luck ;)
c

Wyatt Baldwin | 4 Jun 18:00 2009
Picon

Re: Access to "root" WSGI application


On Jun 4, 2:54 am, Gustavo Narea <m...@...> wrote:
> Hi, Wyatt.
>
> Wyatt said:
>
> > I want to get access to the "root" WSGI middleware, the one that is
> > hit first when a request is made. In this example:
>
> >     [pipeline:main]
> >     pipeline = somefilter auth urlmap
>
> > ...I want access to `somefilter`. I couldn't find a reference to the
> > root app anywhere in the environ. Does anyone know how to access this?
>
> You can't, because it works like this:
> """
> class Middleware1(object):
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         return self.app(environ, start_response)
>
> class Middleware2(object):
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         return self.app(environ, start_response)
>
> class Middleware3(object):
>     foo = "some value"
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         return self.app(environ, start_response)
>
> pylonsapp = make_app(...)
> pylonsapp = Middleware1(pylonsapp)
> pylonsapp = Middleware2(pylonsapp)
> pylonsapp = Middleware3(pylonsapp)
> """
>
> So in Middleware1, for example, you cannot access Middleware3 and vice versa.

Right. In your example, I want access to the `Middleware3` instance--
the WSGI app that is directly served by Paste (or your favorite WSGI
server, X). What I was thinking was that the server machinery could
place a reference to this "root" app in the WSGI environ. I haven't
really thought it through, so perhaps this is a bad idea.

> > For now, I created a wrapper app that saves a reference to itself in
> > the environ.
>
> If you really want it, the standard way to do it is to put in the environ
> whatever you need from that middleware, not the whole middleware.

Well, since it's just a reference, and the object it refers to lives
until the app server dies anyway, I don't think there should be any
issue with sticking it in the environ.

What I'm trying to *do* is a subrequest, based on the original
request:

    req = request.copy()
    # ...modify req.environ here, with a different PATH_INFO, say...
    response = req.get_response(request.environ['wsgi.root_app'])  #
root app gets __call__'ed here with new environ
    return json.loads(response.body)

Maybe our discussion is moot because there's a better way to do
subrequests? I might just need to RTFM a bit more. In the meantime, my
simple wrapper app seems to work fine.

> For example, if what you need is the "foo" argument of Middleware3 in
> Middleware1, you can use this:
> """
> class Middleware1(object):
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         if "middleware3.foo" in environ:
>             # here it is!
>         return self.app(environ, start_response)
>
> class Middleware2(object):
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         return self.app(environ, start_response)
>
> class Middleware3(object):
>     foo = "some value"
>     def __init__(self, app):
>         self.app = app
>     def __call__(self, environ, start_response):
>         # ... do something ...
>         environ["middleware3.foo"] = self.foo
>         return self.app(environ, start_response)
>
> pylonsapp = make_app(...)
> pylonsapp = Middleware1(pylonsapp)
> pylonsapp = Middleware2(pylonsapp)
> pylonsapp = Middleware3(pylonsapp)
> """
>
> Then this value will be available in any middleware* and the application
> itself.
>
> HTH,
>
> PS: Not exactly "any middleware"; it will be available for any middleware
> under it... So if we had a fourth middleware, it wouldn't be able to access
> environ["middleware3.foo"].
> --
> Gustavo Narea <xri://=Gustavo>.
> | Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

Gmane