Re: pyramid_sqla 1.0rc1 released
I see a 'directory' parameter documented in add_static_route(), however the actual implementation doesn't seem to support it. The whole add_static_route() idea is a nice backward-compatible feature with pylons but I feel like it takes away from some of the features pyramid provides, like the static_url() function which can help map arbitrary urls to directories. The static_url() function unfortunately doesn't work with any regular routes, such as those created by add_static_route(), leaving the developer to use either the application_url (effectively hard-coding the structure) or through route_url() which isn't immediately obvious. Anyway I wanted to bring this up in case it can provoke some better documentation for the feature, or possibly not supporting it as the default setup for static content. Thanks again for pyramid_sqla, it does a great job of hooking sqlalchemy into pyramid. Michael On Fri, Jan 28, 2011 at 12:26 AM, Mike Orr sluggos...@gmail.com wrote: On Thu, Jan 27, 2011 at 9:32 PM, Michael Merickel mich...@merickel.org wrote: I'll also point out that the create_db script should probably be initialized with your app's name instead of SimpleDemo in the line: app = get_app(ini_file, SimpleDemo) Thanks for the replies! Michael Hmm, I don't know how that got in there, or why it didn't cause the script to raise an exception. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Fri, Jan 28, 2011 at 1:28 AM, Michael Merickel mmeri...@gmail.com wrote: I see a 'directory' parameter documented in add_static_route(), however the actual implementation doesn't seem to support it. The whole add_static_route() idea is a nice backward-compatible feature with pylons but I feel like it takes away from some of the features pyramid provides, like the static_url() function which can help map arbitrary urls to directories. The static_url() function unfortunately doesn't work with any regular routes, such as those created by add_static_route(), leaving the developer to use either the application_url (effectively hard-coding the structure) or through route_url() which isn't immediately obvious. Anyway I wanted to bring this up in case it can provoke some better documentation for the feature, or possibly not supporting it as the default setup for static content. The point is to give people a choice, and to make the default the backward-compatible way and the way that isn't available in the other templates. The migration guide will compare all these approaches and discuss the tradeoffs between them. You're right that Pyramid URL generation gives more options that Pylons didn't. But the tradeoff is that you have to generate the URL in different ways depending on what it is. That can be seen as a disadvantage, but there's no way around it. I took 'directory' out. It was from an older implementation that didn't pan out. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
I know I've plugged this project before but it seemed relevant to bring up again. I've built Khufu-SQLAHelper to enable what I decided was a best practice to setting up SQLAlchemy in a pyramid project. Daniel Holth and I went back and forth on this a bunch and I think we're mostly in agreement about the approach (was heavily influenced from stucco_auth). http://pypi.python.org/pypi/Khufu-SQLAHelper - Rocky -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
stucco_auth's the approach includes: 1. SQLAlchemy session is only available as request.db (as far as stucco_auth is concerned). 2. Transaction management. No .commit() or .rollback() in view code. 3. Each package has its own declarative_base() and its own versioned schema It has no paster template. It would work fine if request.db = pyramid_sqla.get_session(). I am more interested in the reusability story than the quick start story. Something like: 'pip install pyramid_wiki' root = dict(wiki=pyramid_wiki.Wiki()) create_tables(session, 'pyramid_wiki') config.include(pyramid_wiki.config) http://localhost:6543/wiki/ -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
Is there a reason that a pyramid_sqla template does not add 'pyramid_sqla' as a dependency of the generated project, considering that the project is doing imports from the pyramid_sqla package? Michael On Thu, Jan 27, 2011 at 2:36 PM, Daniel Holth dho...@gmail.com wrote: stucco_auth's the approach includes: 1. SQLAlchemy session is only available as request.db (as far as stucco_auth is concerned). 2. Transaction management. No .commit() or .rollback() in view code. 3. Each package has its own declarative_base() and its own versioned schema It has no paster template. It would work fine if request.db = pyramid_sqla.get_session(). I am more interested in the reusability story than the quick start story. Something like: 'pip install pyramid_wiki' root = dict(wiki=pyramid_wiki.Wiki()) create_tables(session, 'pyramid_wiki') config.include(pyramid_wiki.config) http://localhost:6543/wiki/ -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
Also, is there a reason that the template creates websetup.py as well as scripts/create_db.py? I see that create_db.py is documented, so websetup.py must just be there as an example of how to do it? Michael On Thu, Jan 27, 2011 at 8:06 PM, Michael Merickel mmeri...@gmail.comwrote: Is there a reason that a pyramid_sqla template does not add 'pyramid_sqla' as a dependency of the generated project, considering that the project is doing imports from the pyramid_sqla package? Michael On Thu, Jan 27, 2011 at 2:36 PM, Daniel Holth dho...@gmail.com wrote: stucco_auth's the approach includes: 1. SQLAlchemy session is only available as request.db (as far as stucco_auth is concerned). 2. Transaction management. No .commit() or .rollback() in view code. 3. Each package has its own declarative_base() and its own versioned schema It has no paster template. It would work fine if request.db = pyramid_sqla.get_session(). I am more interested in the reusability story than the quick start story. Something like: 'pip install pyramid_wiki' root = dict(wiki=pyramid_wiki.Wiki()) create_tables(session, 'pyramid_wiki') config.include(pyramid_wiki.config) http://localhost:6543/wiki/ -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Thu, Jan 27, 2011 at 6:06 PM, Michael Merickel mmeri...@gmail.com wrote: Is there a reason that a pyramid_sqla template does not add 'pyramid_sqla' as a dependency of the generated project, considering that the project is doing imports from the pyramid_sqla package? Oh, that makes sense. It never came up during development because oyramid_sqla was already installed in order to create the application. Done. Also, is there a reason that the template creates websetup.py as well as scripts/create_db.py? Removed websetup.py. I was going back and forth on which one to keep, but console scripts are more flexible than websetup.py (you can pass arguments to them and have mutliple scripts). Also, most of websetup's superclass code is for making files, which is irrelevant if you're just creating database tables. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Thu, Jan 27, 2011 at 9:32 PM, Michael Merickel mich...@merickel.org wrote: I'll also point out that the create_db script should probably be initialized with your app's name instead of SimpleDemo in the line: app = get_app(ini_file, SimpleDemo) Thanks for the replies! Michael Hmm, I don't know how that got in there, or why it didn't cause the script to raise an exception. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
pyramid_sqla 1.0rc1 released
pyramid_sqla is now in release candidate status. If I don't hear of any bugs over the next week I'll release the final. 1.0rc1 (2010-01-26) * ‘pyramid_sqla’ application template supports commit veto feature in repoze.tm2 1.0b1. * Add production.ini to application template. * Delete stray files in application template that were accidentally included. Download: http://pypi.python.org/pypi/pyramid_sqla Documentation: https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/index.html Source: http://bitbucket.org/sluggo/pyramid_sqla (The documentation link is lagging behind; I'm not sure if it's bitbucket caching. If it still says version 0.2, see the docs in the source: https://bitbucket.org/sluggo/pyramid_sqla/src/be8422f121b7/docs/ Important note for version 0.1 users: Pyramid 1.0a10 made an incompatible change for applications created with pyramid_sqla 0.1. To use these applications with Pyramid 1.0a10 or later, edit the applications’ setup.py and add ‘pyramid_handlers’ to the ‘requires’ list, and reinstall the applications. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
Why bother wrapping sqlalchemy.engine_from_config? That part seems to take
up most of the code in add_engine(), but when a user has an oddball database
they have to read and understand the wrapper before they can stop using it.
This particular issue was a sore point for me using Pylons' SQLAlchemy
config from the paster template.
Oddball example:
def create_special():
return dbapi.connect('odd database')
import sqlalchemy
e = sqlalchemy.create_engine('oddball://database', creator=create_special)
pyramid_sqla.add_engine(engine=e)
I think you should just require *two* extra lines of boilerplate:
import sqlalchemy
e = sqlalchemy.engine_from_config(settings)
pyramid_sqla.add_engigne(engine=e)
Users can learn more SQLAlchemy and less pyramid_sqla, confident that
add_engine is not doing any magic.
How do I configure a Session() that talks to more than one database? A
SQLAlchemy session can have more than one bind: Session.configure(binds={
User:engine1,
Account:engine2})(http://www.sqlalchemy.org/docs/orm/session.html#enabling-two-phase-commit).
SQLAlchemy will persist each class with its respective database engine.
I encourage you to test your code without _base.metadata.bind = x. Mine
works fine without it, and it is easier to persist the same table to more
than one database engine if the metadata is not bound.
--
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@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Wed, Jan 26, 2011 at 6:35 AM, Daniel Holth dho...@gmail.com wrote:
Why bother wrapping sqlalchemy.engine_from_config? That part seems to take
up most of the code in add_engine(), but when a user has an oddball database
they have to read and understand the wrapper before they can stop using it.
This particular issue was a sore point for me using Pylons' SQLAlchemy
config from the paster template.
Oddball example:
def create_special():
return dbapi.connect('odd database')
import sqlalchemy
e = sqlalchemy.create_engine('oddball://database', creator=create_special)
pyramid_sqla.add_engine(engine=e)
I think you should just require *two* extra lines of boilerplate:
import sqlalchemy
e = sqlalchemy.engine_from_config(settings)
pyramid_sqla.add_engigne(engine=e)
Users can learn more SQLAlchemy and less pyramid_sqla, confident that
add_engine is not doing any magic.
Hi there. I went back and forth on that point, but came down on the
side that most users have one straightforward database and would like
the streamlining of one configuration line. It can handle your
situation too:
# With DB URL in INI file
pyramid_sqla.add_engine(settings, creator=create_special)
# With DB URL as constant
dburl = oddball://database
pyramid_sqla.add_engine(url=dburl, creator=create_special)
One minor annoyance with SQLAlchemy is that you have to import this
from here, that from there, and yon from somewhere else just to
assemble the required boilerplate code. pyramid_sqla provides one way
to simplify this, and the entire module is so small that I think it's
pretty easy to understand and verify it's not doing much magic.
How do I configure a Session() that talks to more than one database? A
SQLAlchemy session can have more than one bind:
Session.configure(binds={User:engine1, Account:engine2})
(http://www.sqlalchemy.org/docs/orm/session.html#enabling-two-phase-commit).
SQLAlchemy will persist each class with its respective database engine.
Did you see the usage page? It's under Different tables bound to
different engines.
https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/usage.html
pyramid_sqla.add_engine(settings, name=engine1, prefix=engine1.)
pyramid_sqla.add_engine(settings, name=engine2, prefix=engine2.)
Session = pyramid_sqla.get_dbsession()
import myapp.models as models
binds = {models.Person: engine1, models.Score: engine2}
Session.configure(binds=binds)
The keys in the binds dict can be SQLAlchemy ORM classes, table
objects, or mapper objects.
I encourage you to test your code without _base.metadata.bind = x. Mine
works fine without it, and it is easier to persist the same table to more
than one database engine if the metadata is not bound.
That's an unusual use case. It's under Two engines, but no default engine.
In this scenario, two engines are equally important, and neither is
predominent enough to deserve being the default engine. This is useful
in applications whose main job is to copy data from one database to
another.
pyramid_sqla.init_dbsession()
pyramid_sqla.add_engine(settings, name=engine1, prefix=engine1.)
pyramid_sqla.add_engine(settings, name=engine2, prefix=engine2.)
Because there is no default engine, queries will fail unless you
specify an engine every time using the bind= argument or
engine.execute(sql).
This gets into the part of pyramid_sqla I'm least satisfied with. The
'name' argument in the above two examples is the most complex part of
the package. If it's not specified or the value is default, this
engine is considered the default engine and is bound to the Session
and metadata. If a name *is* specified, these are not done. The first
example is actually a superset of the second, because any application
that uses 'binds' would probably not have an default engine. I'm
hoping people don't get lost in the differing ways to use 'name' and
how it's sometimes similar to 'prefix'.
All this shows that there are several ways to structure your engines
and models, and it's hard to fit them all into a few functions with
consistent arguments, while still keeping the simplest and most common
use case simple. An earlier draft had a 'init_dbsession()' function
which accepted a 'session_args' argument or sessionmaker, which is
where you would put custom session args like 'binds'. But that seemed
like unnecessary complication because not many people would ever use
that feature, and it's just as easy for them to get the Sessin and
call .config() themselves.
I think the current API covers 80% of the use cases by default, and
with customization can accommodate 95% of them. Most users have only
one database, many want less boilerplate configuration in their
application, and many are new to SQLAlchemy and Python and just want
it to work out of the box so that they can focus on their model
classes. If you find that part of the docs aren't clear enough, I can
work on those sections.
--
Mike Orr sluggos...@gmail.com
--
You received this message because you are
Re: pyramid_sqla 1.0rc1 released
Thanks Mike. Thought at least one person should give you the feedback you
asked for. I must confess I only read your source code and skipped the
documentation.
You may consider stucco_auth's demo application as a counterargument to the
pyramid_sqla design although you could use both packages together. There's a
very small chance that you might also be interested in z3c.saconfig, another
package that attempts to create a global registry of named SQLAlchemy
engines and sessions (and works with the ZopeTransactionExtension by
default).
I'm glad you have thought about `add_engine`. I still think it would be
better for the users to just teach them to type `sqlalchemy.create_engine()`
off the bat by reading the third paragraph of the SQLAlchemy ORM tutorial.
They are going to have to learn SQLAlchemy anyway, SQL eventually, and the
package happens to have an amazing manual that's worth reading all the way
through. The hard parts are things like many-to-many relationships with
foreign keys and circular dependencies in declaratively mapped classes, not
engine creation.
I actually do have to use two database engines that do not participate in
the same transaction (so I cannot use Session(binds={})). Instead, each
database has its own configured session factory. (Upper-case Session is the
session factory, lower-case session is an instance of the session, but with
scoped_session the session factory can be used in almost every case where
you would want an instance.)
--
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@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
Not sure how much speed is a concern, but the StaticViewPredicate here: class StaticViewPredicate(object): def __init__(self, package, subdir): self.package = package self.subdir = subdir def __call__(self, info, request): import logging log = logging.getLogger(__name__) log.setLevel(0) subpath = info[match][subpath] log.debug(subpath is %r, subpath) if not subpath: log.debug(no subpath, returning false) return False parts = [self.subdir] parts.extend(subpath) resource_name = /.join(parts) log.debug(package=%r, resource_name=%r, self.package, resource_name) return pkg_resources.resource_exists(self.package, resource_name) .. could be sped up. Since this predicate will be called many, many times (at least once for each request), it might be wise to: - Import logging at module scope, create a logger at module scope, set level at module scope. or better.. - Don't log here. Logging is very expensive. Also, FWIW, I'd (reverting my prior arguments to the contrary, which I already did here: https://github.com/Pylons/pyramid/issues/closed#issue/44) consider making modules a package if the config.scan() hack (as documented here: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/sqla.html) was injected into the paster template to cause all models to be imported without needing a meta.py and all that stuff. - C On Wed, 2011-01-26 at 01:55 -0800, Mike Orr wrote: pyramid_sqla is now in release candidate status. If I don't hear of any bugs over the next week I'll release the final. 1.0rc1 (2010-01-26) * ‘pyramid_sqla’ application template supports commit veto feature in repoze.tm2 1.0b1. * Add production.ini to application template. * Delete stray files in application template that were accidentally included. Download: http://pypi.python.org/pypi/pyramid_sqla Documentation: https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/index.html Source: http://bitbucket.org/sluggo/pyramid_sqla (The documentation link is lagging behind; I'm not sure if it's bitbucket caching. If it still says version 0.2, see the docs in the source: https://bitbucket.org/sluggo/pyramid_sqla/src/be8422f121b7/docs/ Important note for version 0.1 users: Pyramid 1.0a10 made an incompatible change for applications created with pyramid_sqla 0.1. To use these applications with Pyramid 1.0a10 or later, edit the applications’ setup.py and add ‘pyramid_handlers’ to the ‘requires’ list, and reinstall the applications. -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Wed, Jan 26, 2011 at 12:54 PM, Chris McDonough chr...@plope.com wrote: Not sure how much speed is a concern, but the StaticViewPredicate here: class StaticViewPredicate(object): def __init__(self, package, subdir): self.package = package self.subdir = subdir def __call__(self, info, request): import logging log = logging.getLogger(__name__) log.setLevel(0) subpath = info[match][subpath] log.debug(subpath is %r, subpath) if not subpath: log.debug(no subpath, returning false) return False parts = [self.subdir] parts.extend(subpath) resource_name = /.join(parts) log.debug(package=%r, resource_name=%r, self.package, resource_name) return pkg_resources.resource_exists(self.package, resource_name) .. could be sped up. Since this predicate will be called many, many times (at least once for each request), it might be wise to: - Import logging at module scope, create a logger at module scope, set level at module scope. Oh, that's actually development code that should be taken out. I was just making sure I was checking the right file. Also, FWIW, I'd (reverting my prior arguments to the contrary, which I already did here: https://github.com/Pylons/pyramid/issues/closed#issue/44) consider making modules a package if the config.scan() hack (as documented here: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/sqla.html) was injected into the paster template to cause all models to be imported without needing a meta.py and all that stuff. I'm still concerned that this depends on the order of statements in the modules. As I understand it, config.scan() does a recursive import. But if two modules import each other, then the bottom part of one of them will not have been executed yet, and if the other module depends on something in that lower part, it'll be undefined or otherwise wrong. This can be avoided if you're careful about what you put above and below the import statements, but it can be complex to figure out when this problem will bite and what to put where. Regarding Daniel's concern, what do other people think? Should I make the user call engine_from_config or create_engine himself and pass in an engine object? -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Wed, Jan 26, 2011 at 12:31 PM, Daniel Holth dho...@gmail.com wrote:
I actually do have to use two database engines that do not participate in
the same transaction (so I cannot use Session(binds={})). Instead, each
database has its own configured session factory. (Upper-case Session is the
session factory, lower-case session is an instance of the session, but with
scoped_session the session factory can be used in almost every case where
you would want an instance.)
OK, that's a case where you'd not use pyramid_sqla's Session. Each
part of pyramid_sqla (the Session, engine collection, and Base) is
intended to be a convenience that you can use or not use as you wish.
--
Mike Orr sluggos...@gmail.com
--
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@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
On Wed, Jan 26, 2011 at 12:54 PM, Chris McDonough chr...@plope.com wrote: Also, FWIW, I'd (reverting my prior arguments to the contrary, which I already did here: https://github.com/Pylons/pyramid/issues/closed#issue/44) consider making models a package What do others think? I initially preferred a package because it's directly expandable for larger models. But it was required in Pylons only because of meta.py. I think Pylons previously had model.py earlier, although I may be remembering wrong. A single module is parallel with handlers.py, views.py, etc, as we ship them. Do most Pylons programmers find themselves using multiple model modules most of the time? -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pyramid_sqla 1.0rc1 released
I am working on a Pyramid app and just moved it over to pyramid_sqla. It makes sense to have it as a package because it offers a lot more than just initializing the database. Being able to use the h global and serve static files in a familiar way will make it easier to port Pylons projects and give Pylons developers a consistent way to carry over those ideas into Pyramid (without having to implement them our own ways in every application or end up writing our own package to fulfill the same purpose). As far as the model is concerned, I typically only use a single model. I also prefer the idea of keeping it in a package for easy maintenance and a cleaner models.py. -Eric On Wed, Jan 26, 2011 at 4:23 PM, Mike Orr sluggos...@gmail.com wrote: On Wed, Jan 26, 2011 at 12:54 PM, Chris McDonough chr...@plope.com wrote: Also, FWIW, I'd (reverting my prior arguments to the contrary, which I already did here: https://github.com/Pylons/pyramid/issues/closed#issue/44) consider making models a package What do others think? I initially preferred a package because it's directly expandable for larger models. But it was required in Pylons only because of meta.py. I think Pylons previously had model.py earlier, although I may be remembering wrong. A single module is parallel with handlers.py, views.py, etc, as we ship them. Do most Pylons programmers find themselves using multiple model modules most of the time? -- Mike Orr sluggos...@gmail.com -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
