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 -~----------~----~----~----~------~----~------~--~---
