Pastebin launched a little side project called HostCabi.net, check it out ;-)Don't like ads? PRO users don't see any ads ;-)
Guest

First commit message after dropping django for pyramid

By: a guest on Jul 18th, 2011  |  syntax: None  |  size: 3.04 KB  |  hits: 3,232  |  expires: Never
download  |  raw  |  embed  |  report abuse  |  print
Text below is selected. Please press Ctrl+C to copy to your clipboard. (⌘+C on Mac)
  1.     Initial commit after converting project to SQLAlchemy and Pyramid
  2.    
  3.     I'm not happy about this but ultimately django's lack of support for
  4.     custom database schemas had caused too serious problems for it to be
  5.     worth the effort. Django is clearly not made to be able to comfortably
  6.     interact with a mildly complicated preexisting relational database.
  7.    
  8.     Django's ORM is little more than an object persistence layer that looks
  9.     at the relational database backend as an implementation detail.
  10.     Composite primary keys are plain not supported at all. Certain structure
  11.     is expected and anything else is badly supported. Many-to-many
  12.     relationships that are not implemented like the ORM expects are hard. Each
  13.     object represents exactly one row in one table and it is not supported to
  14.     deviate from that. These and many other issues have cost a lot of time and
  15.     productivity.
  16.     It was my conclusion that django's ORM had to be replaced with SQLAlchemy.
  17.    
  18.     Much of django, including:
  19.      *the authentication framework
  20.      *flatpages and the other "batteries included"
  21.      *the admin interface
  22.      *most reusable apps
  23.     are tightly coupled to the django ORM and thus we would lose those if we
  24.     tried to replace it with SQLAlchemy. Additionally, there is little
  25.     published experience on using django with SQLAlchemy so that option
  26.     might be full of surprises.
  27.    
  28.     Django's admin interface also proved too inflexible for the data, most
  29.     notably due to inlines not being nestable and inlines are required for
  30.     basic things like a (normalized, thus using a table for itself) list of
  31.     names inside a model.
  32.    
  33.     Thus facing inability to use almost all of django's good features and
  34.     having to convert the whole project anyway, I decided to leave django
  35.     out of it for good. I picked pyramid to fill it's place due to it being
  36.     perhaps the biggest and best supported project to use with SQLAlchemy
  37.     and having roots in repoze and Zope, it is well structured for the kind
  38.     of flowing organization data where the data is more important than the
  39.     application.
  40.    
  41.     The new template system is jinja2 which is basically a better designed
  42.     almost-compatable version of django's templating system and most our
  43.     templates work with minimal modifications and the cost of that part of
  44.     the conversion is practically zero. Dispatch was also chosen instead of
  45.     traversal even though traversal might suit this project better due to
  46.     dispatch being almost a drop-in replacement for django's url
  47.     configuration and traversal requiring major architectural changes.
  48.    
  49.     The templates, css and javascript from django's admin interface will be
  50.     reused to prevent having to rewrite it. As features are added and
  51.     designs change, it is expected to be phased out. Form generation is now
  52.     handled by the formalchemy library.
  53.    
  54.     Overall time lost to the conversion is about 3-4 days, which is less
  55.     than the time lost already to fighting django.