Use unit tests so you DO NOT FORGET to user the userid filter.
You're going to walk a thousand miles to get something somewhat working and
that it won't solve all your problems. At least, resolving the "forgetting
the filter" issue is easy to solve.
When you database starts to creep with tables
On Sun, Sep 23, 2012 at 9:32 PM, Rohit Banga wrote:
> How about maintaining one database per department and then using "using"
> parameter to select the appropriate database?
> There are not too many departments. I know it may not scale or seem elegant
> but keeping data
How about maintaining one database per department and then using "using"
parameter to select the appropriate database?
There are not too many departments. I know it may not scale or seem elegant
but keeping data in separate tables or databases is a requirement.
Using the following command I feel I
I don't think so. The question actually had a different point, namely
"When I put a decorator on my model, how do I keep the original name for
the table?" It didn't specify what the decorator does. There is a link to
a doc on proxy models, but it appears that they create multiple tables.
I
Thats interesting Bill.
Are you talking about something like this?
http://stackoverflow.com/questions/3276700/django-model-subclass-without-changing-database-name
Thanks
Rohit Banga
http://iamrohitbanga.com/
On Sat, Sep 22, 2012 at 8:15 PM, Bill Beal wrote:
> Question for
Question for an expert from a newbie: Could you decorate each model that
has data that needs to be separated by departments? If so, you wouldn't
have to remember to code the department filter on each retrieval.
On Friday, September 21, 2012 10:06:35 PM UTC-4, Rohit Banga wrote:
>
> Hi Dennis
Hi Dennis
Thanks for summarizing the contents of the mails.
Do you foresee any problems with the Model Inheritance scheme? At my end I
am stuck at getting a way to achieve dynamic polymorphism - which is
probably because I am new to Python.
I can create a new subclass for every Department I add.
Thanks Nikolas. I think my example was not clear.
But all the code is shared between the departments (another reason for you
to say use the same tables!).
I do not need to have the explicit department name in the code. I don't
know the name of the departments yet! (It is just a metaphor)
I just
If I understand correctly, that's not the type of dynamic loading you
need. That statement can be the much simpler:
>>> from mysite.departments.form import getDepartment
Rather, if you need models (tables) mapped to users at runtime, you need
to load the /those/ dynamically (normally you would
Sure Nikolas I will reconsider your solution.
In case I go for model inheritance then can I use the following solution to
load the class dynamically?
mod = __import__('mysite.departments', fromlist=[form.getDepartment()])
klass = getattr(mod, 'form.getDepartment()')
Thanks
Rohit Banga
Sounds good Joel... Thanks.
What if I want to dynamically create the object of the subclass so that I
don't have to duplicate the code.
If I have
class Department(models.Model):
someField =...
class PhysicsDepartment(Department):
pass
Then how do I instantiate the objects dynamically
I would still argue that the best solution is to use a robust
permissions model which would preclude this. Wherever there is code, you
invariably have the potential for security flaws. The more complicated
you make that code, the more chances for mistakes. On the other hand,
simpler code with
On Fri, Sep 21, 2012 at 4:05 PM, Rohit Banga wrote:
> I just saw this example:
> http://django.readthedocs.org/en/1.4/topics/db/models.html#multi-table-inheritance
>
> Since it is possible for me to have a few number of users (now called
> departments), I can define a
I just saw this example:
http://django.readthedocs.org/en/1.4/topics/db/models.html#multi-table-inheritance
Since it is possible for me to have a few number of users (now called
departments), I can define a create a python file which subclasses all the
models and then run syncdb to update the
Thanks for your comments. I agree that technically it is feasible to
achieve the same affect with row level permissions or filtering the rows by
user.
The requirement is to keep the data separate using different tables,
databases while still using the same model. May be user is not the right
On Fri, Sep 21, 2012 at 2:30 PM, Nikolas Stevenson-Molnar
wrote:
> If you absolutely have to use separate tables per user (again, I do not
> recommend this), then you'll need to implement some form of dynamic models
> (models which can be constructed at run-time rather
If you /absolutely/ have to use separate tables per user (again, I do
not recommend this), then you'll need to implement some form of dynamic
models (models which can be constructed at run-time rather than needing
to be defined in the application code) such as discussed here:
If I understand correctly, what you really need is object (or row) level
permissions. It doesn't make a lot of sense to create a table for each
user, especially when the data model is exactly the same (and could get
you a huge, messy database really quick). Rather, what you want to
control is the
Just HAVE to separate data - requirement.
On Sep 21, 2012 1:59 PM, "Mayukh Mukherjee" wrote:
> As I understand it: (And im fairly new to django too)
>
> A model corresponds to a single table (not multiple).
> The question to you is what is different between User1 and User2
As I understand it: (And im fairly new to django too)
A model corresponds to a single table (not multiple).
The question to you is what is different between User1 and User2 that you
need different tables?
On Fri, Sep 21, 2012 at 1:35 PM, Rohit Banga wrote:
> Hi
>
> I
Hi
I am a django #n00b. I came across the django model documentation and found
it pretty interesting. (
https://docs.djangoproject.com/en/dev/topics/db/models/).
Now my usecase requires I have a set of Models and each model has multiple
tables corresponding to it.
For example when user1
21 matches
Mail list logo