On 01/31/2010 09:07 PM, Mike Orr wrote: > There are several philosophies on this. MVC has strayed far from its > original meaning, and there are several equally valid interpretations > of it. >
Yeah, I just wasn't sure of the best practice in Pylons. The examples seem to use the models as pure ORM maps, with minor exception like the QuickWiki tutorial and the formatting method added to the model. > I prefer a medium model. I have class methods in my ORM objects for > all the logical collections of records my app requires. So one method > to iterate the recent records for the home page. Another to do a > search. Another to iterate all reacords, But I don't resolve queries > into lists. I return the query object so that the controller or > template can iterate it, get a record count, etc. Your approach is very much like mine, with the exception that it is Pylons/SQLAlchemy specific with returning the query object. Good idea because my current practice is to return arrays of model classes (PDO's FETCH_CLASS mode), so that the controller can call individual methods on "rows" of classes if needed. The only drawback to this is separating full vs. limited data, for example if you needed only some fields that make sense in the list, so the method returning these takes a list class fields to load, aside to limit and offset of the rows. Complicated, but imho provides best separation of concerns and with that offers a good level of DRY. Also, good number of row retrievals requires a hierarchical list, so I have a helper class that constructs multilevel arrays (which would be dictionaries in Pylons), and "linear" arrays with appended field that designates its level in otherwise hierarchical list. This is particularly useful when using same set of rows to construct: - tables (pure list of rows) - Navigational constructs (hierarchical dictionaries) - SELECT html elements with '--' added for the number of "levels" it is nested in the tree. But for all that I need the class methods (static methods in PHP) to always return same format of data. Be it classes of models in question or dictionaries. > There are a few people who have been pushing most of their logic into > PostgreSQL stored procedures and triggers, and using its roles to > enforce permissions. Aruynn Shaw has done the most work on this that > I've seen, but last I looked it hadn't gotten onto PyPI and was hard > to find. This looks like the best link: > https://projects.commandprompt.com/public/ > I like to push only data related logic into stored procedures and triggers. If nothing then for one reason: tampering with pure SQL will have same result as if the application interface was used, otherwise one risks corrupting the data. Especially if more than one administrator is involved. I also toyed with having no queries at all in the application except simple calls to stored procedures that deal with the data. This approach for example would turn models into nothing more than simple ORM maps, with a few extra methods that directly call stored procedures. I understand that this might lose the benefit of a certain level of "caching" that occurs within SQLAlchemy... > - Exceptable: convert PostgreSQL exceptions to Python exceptions. > Thanks, I'll be needing this! > - Simpycity: a Python db layer for calling PostgreSQL stored > procedures. (Not compatible with SQLAlchemy.) > I'll take a look. > - VerticallyChallenged: authorization via database roles, with > Repoze.who for authentication. (This one doesn't seem to be online > yet.) > Other than for DB administration, I don't see the point in this. :) But, oh, well... > That's what Exceptable is for. I think it could be made more pythonic, > but I haven't had a need for it myself so I haven't had an incentive > to How else are SQL errors raised in Python, then? I suppose it is driver specific? Thanks, Vlad -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
