Django ACL Design Question
I've spent quite a bit of time investigating several frameworks for a project I am starting. I initially wrote off Django due to it not being able to handle my ACL needs. After reviewing other frameworks I've determined that I will probably have to write something custom regardless of the framework so I thought I would post my problem here and see if anybody can point me in the right direction to get this working in Django. The requirements are as follows: 1.) A user can register with the site 2.) A user can belong to one or more organizations (by invite) 3.) Organizations cannot see each others' data. 4.) A user can have different permissions per organization. So, a user could be an admin in one organization but only be able to view records in another organization. So basically the whole site pivots around an organization id. Permissions need to be stored per organization not for the whole site as the default acl currently works. Think of something similar to a CRM where a person can belong to different organizations that manage their own private records. Any ideas on how to best integrate this with what Django already has or be able to extend it without having to rewrite an Auth/ACL system completely from scratch? If I have to write my own ACL is there a way to integrate it with what Django has? Thanks in advance for any help. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Design Question
Anybody? On Feb 3, 9:41 am, mguthrie <mitchguth...@gmail.com> wrote: > I'm looking at creating an application that would use Django Auth for > managing users but once logged in the user will "belong" only to a > specific organization and can only work with data associated with that > organization. I've looked at using the Django Sites contrib but I > would like something that is dynamically assigned and not specified in > the settings file like sites. > > What would be the best route to adding this functionality? From what > I've looked at so far it might be best to create a Manager that would > handle the model end of things and filter based off of the > organization id. > > Any ideas would be welcome. Also, is there a better way to do this > that wouldn't require having a separate DB for each organization? I > would like each account to be assigned to an organization unless it's > a superuser account which would be able to oversee the entire > application. > > Thanks in advance. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Design Question
I'm looking at creating an application that would use Django Auth for managing users but once logged in the user will "belong" only to a specific organization and can only work with data associated with that organization. I've looked at using the Django Sites contrib but I would like something that is dynamically assigned and not specified in the settings file like sites. What would be the best route to adding this functionality? From what I've looked at so far it might be best to create a Manager that would handle the model end of things and filter based off of the organization id. Any ideas would be welcome. Also, is there a better way to do this that wouldn't require having a separate DB for each organization? I would like each account to be assigned to an organization unless it's a superuser account which would be able to oversee the entire application. Thanks in advance. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django Continuous Integration
I've been working on understanding "agile" programming practices as well as setting up a proper development/testing/release environment. There are several good resources out there for getting these things configured for Python projects in general but nothing really specific to Django. What has worked for other Django developers/shops? How have you managed your processes? Any information on the following would be great: Revision Control: How do you layout your development repository? I'm using Subversion for my setup but would be interested in hearing what else others are using (Mercurial, Bazaar, Git, etc) Packaging: Django has an aversion to using setuptools and opts to stick with the basics in distutils. What are you using for packaging your application? What's the best way to deploy a Django project that would make it easy on the end user to install and configure? I don't really care about providing individual apps. I wish to deploy my application in it's entirety. It would be nice if this could be worked into the development process. Pylons and Turbogears seem to have a nice process setup using Paste and virtualenv that works well for the development and testing process. Do Django users have something similar? Buildbot: Do you use Buildbot or something similar for your Django development? How does that work for you? What other options are there that would work well? Versioning: How do you mark versions of your Django project? Meaning, how can you create your Django app so it has a version that you can track within the application itself as well as for setting up upgrades, etc? I can create something in __init__.py in the root of my project but how does that work with the SCM? Since trunk is always in development it would make sense to have something in there. Do you keep it is a tag or branch? I'm new to this so hopefully I'm making sense. Migrations: What do you use to track database migrations? I know of django-evolution, South and a few others but I really have no idea how these function and which is the most mature. What do you have experience with? That's probably plenty for this post. Sorry it's so long but this is difficult stuff and it's spread out across the internet. Not to mention that it's not specific to Django development. I've recently worked with a Java developer and got a chance to see his development process and was really impressed. Java seems to have more tools available that tie in nicely with each other for continuous integration. He was using Trac, Buildbot, Unit testing (JUnit) and had scripts to deploy to a new server immediately. It was pretty impressive and I would like to know if anyone has something similar setup for their Django projects. Thanks in advance for any input. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Building Django web application
The following link seems to support Graham's conclusion: http://www.technobabble.dk/2008/aug/25/django-mod-wsgi-perfect-match/ -MG On Oct 10, 6:53 pm, mguthrie <[EMAIL PROTECTED]> wrote: > Graham, > Thanks for the detailed response. I have yet to get too much into > the internals of Apache in regards to Python applications. My > background is in PHP which is a whole different beast with it's own > unique way of being tweaked. I'll have to look into the mod_wsgi > setup you mentioned. I've heard a lot of things regarding wsgi with > other Python projects. > Discussing all of this has made me re-think my approach and whether > Django will be a good fit for this specific project. It may be better > for me to simply use a different python framework and let the client > separation be handled via the application and not separated out by > Apache or any other server (lighttpd, nginx, etc). > Like I noted my background is in PHP development so understanding > the Python way of doing things is new territory for me. Thanks for > the feedback. > > -MG > > On Oct 10, 6:29 pm, Graham Dumpleton <[EMAIL PROTECTED]> > wrote: > > > On Oct 11, 9:23 am, mguthrie <[EMAIL PROTECTED]> wrote: > > > > I had read in more than one place that a django instance can eat up to > > > 10mb - 30mb of memory. I don't know whether that is fact or fiction > > > and I'm also confused by the term instance. Is an instance defined as > > > multiple different Django projects or a single Django project used > > > multiple times? If it is true that one Django project used across > > > multiple 's eats up that much memory I wouldn't able able to > > > host very many clients on a server. > > > > I'm trying to devise my infrastructure ahead of time so I'm not stuck > > > with a finished application that can't be hosted for many clients. > > > The comment by Colin about use of multiple sub interpreters not > > requiring much more memory is true, but misleading. This is because as > > you suspect the main issue is how much Django itself takes and not the > > overhead of mod_python or Python sub interpreters. > > > The problem with using mod_python is that Django instances run in sub > > interpreters of Apache child worker processes, thus, how much overall > > memory used is in part dictated by which Apache MPM you are using and > > how many processes Apache has been configured to use. To clarify, > > Apache on UNIX is a multiprocess web server. Thus there isn't just one > > instance of Django per site, but number of Apache child worker > > processes multiplied by the number of sites. > > > If you are are using Apache prefork MPM, it is not uncommon to use a > > configuration that sees minimum 10-20 processes and maximum of 100. > > Thus, if you had 5 sites each running at minimal 20MB, worst case > > where Apache had to create maximum number of processes to handle load, > > would be 5*20*100 MB. A lot of Django sites run with lot more memory > > than 20MB. > > > Using Apache worker MPM, where each Apache child worker process is > > multithreaded can be better, as in that case configuration would > > normally see maximum of 5-10 processes. So, maximum would be 5*20*10 > > MB, which is a lot less. > > > To use Apache worker MPM though, you would need to use Django 1.0 as > > older versions had some question marks over their readiness for > > multithreaded use. Your application itself would also need to > > multithread safe. > > > Now, for another option, you may want to use mod_wsgi instead. Whether > > you use Apache prefork or worker MPM, with mod_wsgi you would create a > > daemon process group for each site and delegate specific WSGI > > applications for each site to run in their own daemon group processes. > > Using daemon mode gives various benefits. These are they each site > > runs in its own processes and no risk of each interfering with each > > other. Each site can run as a distinct user. Individual sites can be > > restarted without restarting whole of Apache. And the number of > > processes used by each site can be be better controlled, with it being > > independent of MPM used and how many Apache child worker processes > > there are. > > > In summary, if you need to be mindful of memory usage, you would be > > better of using mod_wsgi and its daemon mode. This is because it gives > > you separate control over number of processes in use for each site and > > number of processes fixed and isn't variable based on load and Apache > > making a decision to create more worker processes. >
Re: Building Django web application
Graham, Thanks for the detailed response. I have yet to get too much into the internals of Apache in regards to Python applications. My background is in PHP which is a whole different beast with it's own unique way of being tweaked. I'll have to look into the mod_wsgi setup you mentioned. I've heard a lot of things regarding wsgi with other Python projects. Discussing all of this has made me re-think my approach and whether Django will be a good fit for this specific project. It may be better for me to simply use a different python framework and let the client separation be handled via the application and not separated out by Apache or any other server (lighttpd, nginx, etc). Like I noted my background is in PHP development so understanding the Python way of doing things is new territory for me. Thanks for the feedback. -MG On Oct 10, 6:29 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On Oct 11, 9:23 am, mguthrie <[EMAIL PROTECTED]> wrote: > > > I had read in more than one place that a django instance can eat up to > > 10mb - 30mb of memory. I don't know whether that is fact or fiction > > and I'm also confused by the term instance. Is an instance defined as > > multiple different Django projects or a single Django project used > > multiple times? If it is true that one Django project used across > > multiple 's eats up that much memory I wouldn't able able to > > host very many clients on a server. > > > I'm trying to devise my infrastructure ahead of time so I'm not stuck > > with a finished application that can't be hosted for many clients. > > The comment by Colin about use of multiple sub interpreters not > requiring much more memory is true, but misleading. This is because as > you suspect the main issue is how much Django itself takes and not the > overhead of mod_python or Python sub interpreters. > > The problem with using mod_python is that Django instances run in sub > interpreters of Apache child worker processes, thus, how much overall > memory used is in part dictated by which Apache MPM you are using and > how many processes Apache has been configured to use. To clarify, > Apache on UNIX is a multiprocess web server. Thus there isn't just one > instance of Django per site, but number of Apache child worker > processes multiplied by the number of sites. > > If you are are using Apache prefork MPM, it is not uncommon to use a > configuration that sees minimum 10-20 processes and maximum of 100. > Thus, if you had 5 sites each running at minimal 20MB, worst case > where Apache had to create maximum number of processes to handle load, > would be 5*20*100 MB. A lot of Django sites run with lot more memory > than 20MB. > > Using Apache worker MPM, where each Apache child worker process is > multithreaded can be better, as in that case configuration would > normally see maximum of 5-10 processes. So, maximum would be 5*20*10 > MB, which is a lot less. > > To use Apache worker MPM though, you would need to use Django 1.0 as > older versions had some question marks over their readiness for > multithreaded use. Your application itself would also need to > multithread safe. > > Now, for another option, you may want to use mod_wsgi instead. Whether > you use Apache prefork or worker MPM, with mod_wsgi you would create a > daemon process group for each site and delegate specific WSGI > applications for each site to run in their own daemon group processes. > Using daemon mode gives various benefits. These are they each site > runs in its own processes and no risk of each interfering with each > other. Each site can run as a distinct user. Individual sites can be > restarted without restarting whole of Apache. And the number of > processes used by each site can be be better controlled, with it being > independent of MPM used and how many Apache child worker processes > there are. > > In summary, if you need to be mindful of memory usage, you would be > better of using mod_wsgi and its daemon mode. This is because it gives > you separate control over number of processes in use for each site and > number of processes fixed and isn't variable based on load and Apache > making a decision to create more worker processes. > > Note that mod_wsgi and daemon mode doesn't preclude you still running > a site within embedded mode, ie., in Apache child worker processes, at > the same time if you feel that the bit of extra speed coming from > embedded mode is important to you for a specific site. > > Graham > > > Thanks for replying. > > > -MG > > > On Oct 10, 2:58 pm, "Colin Bean" <[EMAIL PROTECTED]> wrote: > > > > On Fri, Oct 10, 2008 at 12:34 PM, mguthrie <[EMAIL PROTECTED]> wrote: >
Re: Building Django web application
I had read in more than one place that a django instance can eat up to 10mb - 30mb of memory. I don't know whether that is fact or fiction and I'm also confused by the term instance. Is an instance defined as multiple different Django projects or a single Django project used multiple times? If it is true that one Django project used across multiple 's eats up that much memory I wouldn't able able to host very many clients on a server. I'm trying to devise my infrastructure ahead of time so I'm not stuck with a finished application that can't be hosted for many clients. Thanks for replying. -MG On Oct 10, 2:58 pm, "Colin Bean" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2008 at 12:34 PM, mguthrie <[EMAIL PROTECTED]> wrote: > > > I've been looking into Django for building something that is more web > > application than it is website. I understand that Django has been > > developed in a sort of CMS mindset but to date I haven't found any > > reason why it couldn't create non-content centric web apps as well. > > > My project requirements are as follows: > > > 1.) I need to be able to host this project for multiple clients. No > > customization, just everybody using the same thing. Therefore ideally > > they should all share the same codebase. > > 2.) Each client should have their own user table/authentication since > > I want client A to be able to have a user named john.doe and client B > > to as well. I would not mind if they shared the same table but they > > needed to provide a client id so the login can differentiate. > > 3.) Media should be separate per client. Client A media should not be > > mixed with Client B or vice versa. > > 4.) Database either needs to be single db per client or one large db > > with multiple prefixed tables per client. So each client would get > > their own users table (or shared table with client id field), tables > > for data, etc. > > > I've researched the options available and here's what I've found > > (correct me if I'm wrong): > > 1.) I can host each client separately by providing a different > > for each and specifying a different settings file. This > > should allow me to specify separate DB's, media locations, etc but I'm > > concerned about the overhead of hosting them. I've read that for each > > instance of Django requires another python interpreter. If that is > > the case wouldn't I run out of RAM quickly hosting several clients? > > Is there a way I can do this using only one instance of Django? If I > > use Django with multiple 's per client would that be one > > Django instance or multiple? Is mod_python not the way to go for this > > project? > > 2.) I can use django.contrib.sites but every client shares the > > authentication. Is there a way I can specify a client id to > > distinguish Client A's john.doe from Client B's? If I do this can I > > specify where media for either would go? How about they all share the > > same DB but have different table prefixes? > > > I know it's a lot but I wanted to be as specific as I could so I don't > > waste someone's time. Is Django probably the wrong framework for this > > project? Should this be a Pylons/Turbogears thing or what? > > > All ideas/critiques/reworkings will be accepted. Thanks in advance. > > > -MG > > Django is quite capable of doing everything you described. You've > almost answered your own question because hosting separate django > instances under different directives (or virtual hosts) > seems like the ideal solution. I wouldn't worry too much about the > overhead of multiple python interpreters -- if python is using shared > libraries, they will use a little extra ram, but I doubt they will > exhaust your system resources before something else does. I don't > have any numbers to back this, but I've run several django instances > on a single host with no problem, and it seems to be fairly common > practice. > > Colin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Building Django web application
I've been looking into Django for building something that is more web application than it is website. I understand that Django has been developed in a sort of CMS mindset but to date I haven't found any reason why it couldn't create non-content centric web apps as well. My project requirements are as follows: 1.) I need to be able to host this project for multiple clients. No customization, just everybody using the same thing. Therefore ideally they should all share the same codebase. 2.) Each client should have their own user table/authentication since I want client A to be able to have a user named john.doe and client B to as well. I would not mind if they shared the same table but they needed to provide a client id so the login can differentiate. 3.) Media should be separate per client. Client A media should not be mixed with Client B or vice versa. 4.) Database either needs to be single db per client or one large db with multiple prefixed tables per client. So each client would get their own users table (or shared table with client id field), tables for data, etc. I've researched the options available and here's what I've found (correct me if I'm wrong): 1.) I can host each client separately by providing a different for each and specifying a different settings file. This should allow me to specify separate DB's, media locations, etc but I'm concerned about the overhead of hosting them. I've read that for each instance of Django requires another python interpreter. If that is the case wouldn't I run out of RAM quickly hosting several clients? Is there a way I can do this using only one instance of Django? If I use Django with multiple 's per client would that be one Django instance or multiple? Is mod_python not the way to go for this project? 2.) I can use django.contrib.sites but every client shares the authentication. Is there a way I can specify a client id to distinguish Client A's john.doe from Client B's? If I do this can I specify where media for either would go? How about they all share the same DB but have different table prefixes? I know it's a lot but I wanted to be as specific as I could so I don't waste someone's time. Is Django probably the wrong framework for this project? Should this be a Pylons/Turbogears thing or what? All ideas/critiques/reworkings will be accepted. Thanks in advance. -MG --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
