Thanks a lot Malcolm! I'll start moving the TurboGears hand-written admin to the Django admin and keep MySQL.
I've one more philosophic question: The model in Django should hold the business rules, right? So let's say that there's a "product" class that knows to calculate it's "stock" through the addition of stock- movements. That's coded as a function in the "product" class. That business rule/algorithm is only available within Django and not in any other front-end accessing the same MySQL database through ODBC for instance. Obvious! If business rules have to be available outside Django then they have to be coded as stored procedures in the database in yet another language (PL-Sql or whatever ...). That's sort of a pity. Might there be a technical way to "serve" the database to an ODBC client through Django? Marc On Apr 8, 4:54 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Tue, 2009-04-07 at 14:31 -0700, mettwoch wrote: > > Hi, > > > I've been watching Django and other Python frameworks a few years ago > > and stopped at version 0.96. Last year I started to look at a web > > framework to move an old M$ Access Inventory application to a more > > stable and universal architecture. Turbogears was the choice and a few > > weeks ago I rediscovered Django and now I feel baaaaad! I've spent > > hours and hours to build an admin interface in TG and Django 1.+ now > > has everything I missed in 0.96. Guys, I'm back to Django! > > > There's nothing time critical with that app because the Access thing > > does the trick, but I'd like to do it all the right way this time! > > > So I've a set of questions: > > > - Might SQLite be a viable choice for an "ERP" type application with a > > lot of updates? I've experienced lock problems with SQLite in other > > frameworks using SQLObject! > > SQLite isn't a particularly strong choice for concurrent access > situations. For predominantly single-user access, things are better. > There's still some locking overhead, since it is file-based, rather than > network server based. If you want a high performance database, use a > high performance database (MySQL or PostgreSQL, for example). If you > want an embeddable system, SQLite is awesome. > > > > > - We use multiple languages in my country (FR, EN, DE, ...). Is > > Unicode the right choice (UTF-8)? > > Yes. > > > > > - Could a project be "ERP" and the applications "FO" and "BO" (Front- > > and Back-Office)? > > You're using a lot of buzzwords. What do you mean? Those terms can (and > do) mean pretty much anything to many people. Can you ask a more > concrete question about what problem you're trying to solve? > > > Would the model be located in the project rather > > than in one of the applications as per default? > > Models live inside applications. Period. If you've got something with a > model in it that you want to be usable through Django, you have to put > the containing module into the INSTALLED_APPS setting, which makes it, > by definition, an application. > > A Django "project" is just a collection of applications, a settings file > and a root URL conf file. > > > The model is shared by > > FO and BO and doesn't especially belong to one of these! BO will be > > mostly "Django admin" style + some business reports and some OLAP > > while FO is essentially Point-Of-Sales stuff! > > I fell you might be thinking about this in the wrong terms. Drop the > concept of "ownership", since that's irrelevant to running code. If two > pieces of functionality -- possibly accessible via different web servers > or whatever -- need to use the same application, then that's no problem. > Just put the application into the INSTALLED_APPS setting for both of > them. > > > > > - What might be a typical Dev/Test/Prod environment with Django? > > Multiple db schemes prj_dev, prj_tst, prj_prd? > > That's possible. Separate machines is also pretty common -- development > on a local machine, roll out to a staging system, then deploy. Dev and > staging might well have databases and webserver and caching servers > could all be on the same machine. Then in production, things might be > split up over multiple machines a bit more. > > > > > I'd like to be up and producing code soon because the db Model is > > mature and the migration strategy is clear in my head, but I need some > > guidance to set me on track with the Django philosophy. > > The general guidance I give to everybody about this is to not sweat the > small stuff too much. What you write in your first few applications > isn't going to be the same as what you would write a month or two or 24 > down the track. There are lots of ways to do things, which is good. So > pick something that works, be prepared to experiment and don't worry if > it's not necessarily what other people are doing, because there are > multiple right answers. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
