#pyramid

I'm taking notes. So it's more reassuring if the docs expressly give examples that show pyramid-specific situations?

I mean, I try to keep it somewhat agnostic, like this: http://hendrix.readthedocs.org/en/latest/testin...

you're not getting it

the docs don't actually show running a wsgi app

any wsgi app

But naturally I just haven't gone through and done that with the rest of the docs

Oh I see. You want to see the application object be passed somewhere.

Yeah, that's totally sensible.

gunicorn and uwsgi both have ways to run apps made with pastedeploy directly

what the docs on http://hendrix.readthedocs.org/en/latest/runnin... show, and the ONLY thing they show, is "running a django app by passing in the location of the django settings"

those aren't pyramid-specific but work with pyramid apps

(which obviously i can't do for pyramid)

"gunicorn --paste development.ini" or whatever

inklesspen: Yeah I agree that's awful.

if hendrix is doing any monkeypatching of threadlocals then it's important to not make an entrypoint for it in pserve

s/threadlocals/threading

I haven't been exposed to pastedeploy prior to this moment.

jMyles: pastedeploy is the system that pyramid's ini file tooling uses

inklesspen: Well, it's not much, but I've made this doc a tiny bit more agnostic: http://hendrix.readthedocs.org/en/latest/runnin...

inklesspen: Yeah, I've been looking into it here these past minutes.

I need to get some... rest if not sleep.

Talk to you all soon.

Hello, I'm reading http://pyramid-cookbook.readthedocs.org/en/late... and I can't seem to figure out if the 2nd database should be added to __init__.py? or elsewhere.. I don't want the initialize_myapp_db to touch it

wherever

pyramid cares not at all about dbs

do you mean "I'm using sqlalchemy and I'm not sure how to do models against multiple dbs"

rweir: I mean the default DB is sqllite...when you do initlize_myapp_db it will create default tables for session,etc.... I've added a 2nd db that I will use to pull database from mysql using sqlalchemy...but I want to make sure that initilize script will not be trying to create tables in mysql...only in sqllite

so the real question is : does the initialize_tutorial_db development.ini calls def main() in __init__ or?

pyramid has no idea about dbs

it does...because scafold is setting it up...and by default it wants sqlite. aka sqlalchemy.url I'

The scaffold is simply a tool to help you get started. If you look in scripts/initdb.py (IIRC) you can see what it is doing to create your SQLite database.

As long as you don't call the same functions on your new models/DBSession that is tied to MySQL it won't do any initialisation for you.

I'm adding a second one mydatabase2.url = mysql://.... now I want to add a engine2 = engine_from_config(settings, 'mydatabase2.') DBSession.configure(bind=engine2)

You can't name it the same "DBSession"

so long as you make that DBSession2 you should be fine.

sorry DBSession2...

inside __init__....will that database be called when I do inililize_myapp_db development.ini

Go read script/initdb.py which the scaffold created for you.

that is what initialize_myapp_db points to...

It's an entrypoint that is located in your setup.py

Pyramid itself is entirely database agnostic, the scaffold in this case uses sqlalchemy to give you a starter project, there is no requirement for you to use the scaffold though,

x58...thank you..it looks like its using DBSession DBSession.add(model)

There is no magic there... unless you explicitly tell it to initialise your MySQL database in that script, it just won't happen.

Explicit over implicit.

one more....Reflected tables ...def init_model(enigine2):.....autoload=True....does that go into __init__.py or models.py?

Up to you.

You can organise the code how you see fit.

I guess model.py...now that I look at it closely and I see original DBSession is there...and I guess I'm going to have to call init_model(engine2) in __init__.py

thank you...gtg to to sleep now...resume tomorow..bye .(http://lucasmanual.com/mywiki/Pyramid/)

morning

Good morning.

cdunklau: I think I'd favour something like the repository pattern for CRUD stuff.

But for the more adventurous stuff I think I'd better tempted to use view properties. The problem with some DB stuff is that too much abstraction just creates new problems.

DRY tempts us to try and avoid writing two very similar, but subtly different queries.

I think SQLa's SQL generation code is. however, good enough for us not to worry about it too much. So writing the query where you need it seems the way to go.

Charlie_X: i'm not really sure what you mean by "view properties"...

Use a class for the view and use properties on it.

View methods and attributes are visible to any template.

Allows you to encapsulate stuff without littering your code with lots of utility functions.

Makes a lot of sense if you have a lot of queries for a page.

Charlie_X: oh good to know

Charlie_X: i do like the repository pattern idea. even if I have a repository method i'll only use once, it still makes things more testable

Yes

It's basically stating the obvious. But that's often no bad thig.

cdunklau: you can have a laugh at some thoroughly untested view code

I think this shouldn't take too much work to become reasonably testable: https://bitbucket.org/charlie_x/python-httparch...

Charlie_X: oh so you actually meant properties

whyyyy

Charlie_X: that is, why not just normal methods?

Simplifies accessing them and clarifies intent.

hmm, i'd be surprised if attribute access did a bunch of things

but oh well

so here's what i have for my repository thing so far. it feels dirty, instances of those classes hold no state

oh rats, charlie left