Re: [pylons-devel] Best Practices with ORM use

[Mike Orr]

On Fri, Jan 8, 2016 at 12:55 AM, Torsten Irländer  wrote:
> But I wasn't aware of that
> this
> could be a topic for a talk. Actually I thought this is kind of a hack but
> is
> seems to be not bad :D.

Organizing business logic has been a perennial issue for Pyramid and
Pylons developers forever. I started with high-level class methods and
instance methods in the ORM classes (depending on whether it's
operating on a single record or querying multiple ones), but I did all
the updating in the views. That led to two problems: the model modules
became large and cumbersome, and the views had so many unrelated
things intertwined. For the model problem I first extracted the
searching routines to separate classes in the model (SomethingQuery
classes).

Another thing I've long disliked was mixing presentation code and data
code in the views (Pylons controllers). The only choice was to put
formatting code in the Mako templates, and then if there's an
exception the traceback was often too generic and wouldn't tell you
where, or in the views with other stuff. Again I went maximum-template
approach, then minimum-template (a la mustache), then in between.

Later I was inspired by Mike Merickel's pyramid_services and the
Model-View-Presenter [1] paradigm. I tried pyramid_services but
couldn't find a good reason for adding the complication of the
registry class-matching stuff. So I ended up making my own service
classes that the views instantiate directly. The services handle
business logic, and the views focus mostly on Pyramid interaction
(form input, rendering variables).

I try to keep Pyramid-specific and presentation-specific things out of
the services, with three minor exceptions. One, services have a
'from_request' class method that extracts their data from the request
(e.g., database sessions using reified properties, engines using
"global" registry attributes). Two, they sometimes raise an
HTTPException if the caller would just do that anyway. I figure unit
tests can deal with an HTTPException as easily as some other
exception. Three, I sometimes have model methods or service methods
return a presentation-friendly value (JSONable dict, formatted string)
to avoid duplication and put the formatter close to the data fields.

[1] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Torsten Irländer]

Am Donnerstag, 7. Januar 2016 17:39:56 UTC+1 schrieb Paul Everitt:
 

> For the O’Reilly video series on Pyramid (and for the proposed PyCon talk 
> with @mmerickel), I emphasized route factories. Move the location of the 
> model instance out of the view and into the framework, namely, a context 
> variable passed into the view.
>
> I then moved more helper-style logic into the model class.
>
> I then made the model class into a “service" for operations that don’t yet 
> have an instance, e.g. list all invoices, add an invoice, search for 
> invoices. These became class methods on the SQLAlchemy model. My route 
> factory then learned whether to return an instance or the class, as the 
> context.
>
> After that, the views don’t do much. I reached the same point as 
> Jonathan…views were just for view-y stuff (handling form data, massaging 
> output formats, whatever.)
>
> Arranging to have a “context” is a pattern I’d love to see emphasized more.
>
> —Paul
>
> On Jan 7, 2016, at 11:03 AM, Jonathan Vanasco  > wrote:
>
> In my experience, the standard scaffold way is perfect for most uses.
>
> If your codebase grows very large, or you start needed to run non-pyramid 
> services, you may need to rethink things.
>
> One of my projects outgrew the typical 'views' approach.  Now, we 
> prototype the functionality onto the views but then create functions that 
> do all the real work in a `lib.api` namespace.  The views just format data 
> for the internal api and pass in the right arguments.  The main reason why 
> migrated to this approach, is that a lot of shell scripts / celery 
> functions / twisted functions (and some microservices tested out in flask) 
> were all needing to do the same things.  Now we just import a core library 
> that has the models and api into whatever application.
>
> Just to be a bit more clear, in our approach:
>
> * pyramid + view = validate form data, handle form responses, decide what 
> to query/insert/update/etc
> * model + api = accepts formatted args and connections to database + 
> request/caching layer for routine tasks.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-devel...@googlegroups.com .
> To post to this group, send email to pylons...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
:) Nice to see that Michael proposed a talk for PyCon on this topic. I am 
also
using this pattern in Ringo[0] and like the fact that this really makes 
views
more general and life more easy as developer. But I wasn't aware of that 
this
could be a topic for a talk. Actually I thought this is kind of a hack but 
is
seems to be not bad :D.

However in my case I am using this pattern to implement typical CRUD
operations on the given context. There are some base views for each 
operation
in CRUD which still does the main logic on the given context but the logic 
is
general and the same for all resources. Specific logic is then put in the
model.

Thanks to the flexibility of Pyramid its also possible to overwrite the view
config and add custom pre or post logic into the view which doesn't fit well
into the logic.

In my case
+1 for that. I am also using route factories a lot and they really tend to
make life easier.

Have a nice day!

[0] http://www.ringo-framework.org 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Danuel Williams]

Well I guess it does help me, because the way you describe doing it is
exactly how I currently have it implemented

On Wed, Jan 6, 2016 at 8:30 PM, Karl O. Pinc  wrote:

> On Wed, 6 Jan 2016 13:35:18 -0800 (PST)
> Danuel Williams  wrote:
>
> > Currently I am developing an application where I initialize some
> > mapped tables from my DB via ORM (SqlAlchemy) within a module, and
> > then I import these tables into the views I need and then perform
> > operations on them within the views. This actually irks me a bit as I
> > feel that I should be doing all my DB work within that same module
> > within which I initialized my mapped tables. I am just wondering what
> > best practices dictate when it comes to using an ORM with Pyramid.
>
> I can't really speak to "best practices".  I use the method
> of the pyramid orm scaffold.  A module to declare the models,
> mystuff/__init__.py imports Base and DBSession and it's main()
> uses them to setup SQLAlchemy with an engine.  Then the views
> import the model classes and do the work.  SQLAlchemy takes care
> of the details involved in loading new class objects with db content
> and making changes persistent.
>
> Does this help?
>
> Karl 
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Paul Everitt]

For the O’Reilly video series on Pyramid (and for the proposed PyCon talk with 
@mmerickel), I emphasized route factories. Move the location of the model 
instance out of the view and into the framework, namely, a context variable 
passed into the view.

I then moved more helper-style logic into the model class.

I then made the model class into a “service" for operations that don’t yet have 
an instance, e.g. list all invoices, add an invoice, search for invoices. These 
became class methods on the SQLAlchemy model. My route factory then learned 
whether to return an instance or the class, as the context.

After that, the views don’t do much. I reached the same point as Jonathan…views 
were just for view-y stuff (handling form data, massaging output formats, 
whatever.)

Arranging to have a “context” is a pattern I’d love to see emphasized more.

—Paul

> On Jan 7, 2016, at 11:03 AM, Jonathan Vanasco  wrote:
> 
> In my experience, the standard scaffold way is perfect for most uses.
> 
> If your codebase grows very large, or you start needed to run non-pyramid 
> services, you may need to rethink things.
> 
> One of my projects outgrew the typical 'views' approach.  Now, we prototype 
> the functionality onto the views but then create functions that do all the 
> real work in a `lib.api` namespace.  The views just format data for the 
> internal api and pass in the right arguments.  The main reason why migrated 
> to this approach, is that a lot of shell scripts / celery functions / twisted 
> functions (and some microservices tested out in flask) were all needing to do 
> the same things.  Now we just import a core library that has the models and 
> api into whatever application.
> 
> Just to be a bit more clear, in our approach:
> 
> * pyramid + view = validate form data, handle form responses, decide what to 
> query/insert/update/etc
> * model + api = accepts formatted args and connections to database + 
> request/caching layer for routine tasks.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-devel+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to pylons-devel@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/pylons-devel 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Jonathan Vanasco]

In my experience, the standard scaffold way is perfect for most uses.

If your codebase grows very large, or you start needed to run non-pyramid 
services, you may need to rethink things.

One of my projects outgrew the typical 'views' approach.  Now, we prototype 
the functionality onto the views but then create functions that do all the 
real work in a `lib.api` namespace.  The views just format data for the 
internal api and pass in the right arguments.  The main reason why migrated 
to this approach, is that a lot of shell scripts / celery functions / 
twisted functions (and some microservices tested out in flask) were all 
needing to do the same things.  Now we just import a core library that has 
the models and api into whatever application.

Just to be a bit more clear, in our approach:

* pyramid + view = validate form data, handle form responses, decide what 
to query/insert/update/etc
* model + api = accepts formatted args and connections to database + 
request/caching layer for routine tasks.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Karl O. Pinc]

On Wed, 6 Jan 2016 13:35:18 -0800 (PST)
Danuel Williams  wrote:

> Currently I am developing an application where I initialize some
> mapped tables from my DB via ORM (SqlAlchemy) within a module, and
> then I import these tables into the views I need and then perform
> operations on them within the views. This actually irks me a bit as I
> feel that I should be doing all my DB work within that same module
> within which I initialized my mapped tables. I am just wondering what
> best practices dictate when it comes to using an ORM with Pyramid.

I can't really speak to "best practices".  I use the method
of the pyramid orm scaffold.  A module to declare the models,
mystuff/__init__.py imports Base and DBSession and it's main() 
uses them to setup SQLAlchemy with an engine.  Then the views 
import the model classes and do the work.  SQLAlchemy takes care 
of the details involved in loading new class objects with db content
and making changes persistent.

Does this help?

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Best Practices with ORM use

[Danuel Williams]

Hi, 

Currently I am developing an application where I initialize some mapped 
tables from my DB via ORM (SqlAlchemy) within a module, and then I import 
these tables into the views I need and then perform operations on them 
within the views. This actually irks me a bit as I feel that I should be 
doing all my DB work within that same module within which I initialized my 
mapped tables. I am just wondering what best practices dictate when it 
comes to using an ORM with Pyramid.

Thanks,
Danuel Williams 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.