"Dynamyc" modells
airween
I don't know how can I tell you my question :)
There are many lists - lists contains items (in this case those items
are promotion codes for marketing agencies, but it doesn't matter).
I need (I want) to store every lists in different table.
I can make a List model, which describes name of list, table which
contains items, and so on.
But then, I want to use every lists as List model - is it possible? I
mean, I can use get(), filter() and other methods of model.
If yes, what should I read to know this?
Thanks:
a.
Shawn Milochik
your own data, since it's a Python built-in. Maybe CodeList or PromoList
or something, if they're going to be promotion codes. Or maybe just
Promo, since a model should be a singular name, and each instance of
your model will be a single item, not actually a list.
I think you can do what you want my making a class that subclasses
models.Model, then subclassing that with all of your other classes.
As long as you don't make the base class "abstract," adding instances to
any subclass will create an instance of the base class.
I think that answers your question, but I don't understand your
description well enough to claim that this is the best approach to the
problem you're trying to solve.
Shawn
Ervin Hegedüs
thanks for the reply.
On Mon, Mar 12, 2012 at 03:20:10PM -0400, Shawn Milochik wrote:
> First, I would avoid using the word 'list' for describing anything
> in your own data, since it's a Python built-in. Maybe CodeList or
> PromoList or something, if they're going to be promotion codes. Or
> maybe just Promo, since a model should be a singular name, and each
> instance of your model will be a single item, not actually a list.
well, you're right, using "list" should misleading - thanks.
> I think you can do what you want my making a class that subclasses
> models.Model, then subclassing that with all of your other classes.
>
> As long as you don't make the base class "abstract," adding
> instances to any subclass will create an instance of the base class.
>
> I think that answers your question, but I don't understand your
> description well enough to claim that this is the best approach to
> the problem you're trying to solve.
umm, no, sorry, I've wrote my problem incomplete.
The main problem is the PromoList is _dynamyc_ - it means all
administrator on admin site should add new PromoList, without me
:), so I can't derivate all subclass in code...
May be this would be clear....
Thanks:
a.
--
I � UTF-8
Shawn Milochik
> The main problem is the PromoList is _dynamyc_ - it means all
> administrator on admin site should add new PromoList, without me
> :), so I can't derivate all subclass in code...
>
You can't dynamically create database tables on the fly. That would
require real-time schema migrations, which would be a bad idea even if
you got it to work.
Why not make one model, give it an extra field for the description of
what type of promo it is, and just add records to the same model for
each "type" of promo code?
Ervin Hegedüs
Hello,
2012.03.12. 20:48, "Shawn Milochik" <sh...@milochik.com> ezt írta:
>
> On 03/12/2012 03:34 PM, Ervin Hegedüs wrote:
>>
>> The main problem is the PromoList is _dynamyc_ - it means all
>> administrator on admin site should add new PromoList, without me
>> :), so I can't derivate all subclass in code...
>>
>
> You can't dynamically create database tables on the fly.
That's not true. Currently I'm using this way, which I described above, just I can't use Model methods. When admin creates a new record, Django creates a new table trough save hook.
>
> Why not make one model, give it an extra field for the description of what type of promo it is, and just add records to the same model for each "type" of promo code?
Some promotion has few millions of records, different promotions have different format of codes, ... And general: I'm looking for an ultimate solution, and may be the next time every ListRecord will have different columns.
Thanks:
a
Jani Tiainen
> On Mon, 12 Mar 2012 22:14:27 +0100, Ervin Heged�s<air...@gmail.com>
> declaimed the following in gmane.comp.python.django.user:
>
>
>> Some promotion has few millions of records, different promotions have
>> different format of codes, ... And general: I'm looking for an ultimate
>> solution, and may be the next time every ListRecord will have different
>> columns.
>>
> AS the application, rather than just USING a DBMS...
Ultimate solution sounds more like using document oriented databases,
like CouchDB or MongoDB. (Just the few I happened to remember).
> That is: maintaining a data dictionary which contains "promotion
> format", "promotion field", "field type", (maybe field position too,
> along with fields to identify constraints on the valid values); and a
> related data table in which each record holds just ONE field, with a
> foreign key referencing the specific "promotion format/field" pair along
> with a field containing the "record ID" (since any actual record will
> take more than one table entry). The data value itself is likely going
> to be a BLOB [unless you are using SQLite where you can store anything
> in a field], and you use the type information to determine how to
> interpret the value.
That's doable but will be pain in the ass to maintain. Also performance
is not that good since it wouldbe RDBMS on top of RDBMS.
Also all database CRUD operations would be handcrafted still. I would
definitely look using those document oriented databases which would
allow doing all that fancy stuff without too much sweat.
--
Jani Tiainen
Ervin Hegedüs
On Mon, Mar 12, 2012 at 09:51:43PM -0400, Dennis Lee Bieber wrote:
> On Mon, 12 Mar 2012 22:14:27 +0100, Ervin Hegedüs <air...@gmail.com>
> declaimed the following in gmane.comp.python.django.user:
>
>
> > Some promotion has few millions of records, different promotions have
> > different format of codes, ... And general: I'm looking for an ultimate
> > solution, and may be the next time every ListRecord will have different
> > columns.
> >
> Strangely, your "ultimate solution" might mean implementing a DBMS
> AS the application, rather than just USING a DBMS...
>
> That is: maintaining a data dictionary which contains "promotion
> format", "promotion field", "field type", (maybe field position too,
> along with fields to identify constraints on the valid values);
[...]
yes, it's absolutely true.
But :), I'm so far from there I implement full of these.
It's no problem, I'm just looking for a good solution, first it
could be enough to implement all() method (and filter()), and
there is an important invariant: in my (all) cases, the different
ListItems has an intersect of columns, I mean there are a few
columns, which exists in all ListItems object.
Any idea?
Ervin Hegedüs
On Tue, Mar 13, 2012 at 09:38:34AM +0200, Jani Tiainen wrote:
> Ultimate solution sounds more like using document oriented
> databases, like CouchDB or MongoDB. (Just the few I happened to
> remember).
okay, lets look an another example: I have a model, which
describes RDBMS connections: DBdesc, DBhost, DBuser, DBpassword,
DBdbname, DBtable, DBkeycolumn, DBvalcolumn, and so on...
Now I can filter() a row by DBdesc, which gives me de full
description of DB connection - sometimes that DB exists on an
external host. As I wrote my previous email, all data model in
different data source have an intersect of columns, these columns
are stored in my model.
(Security is important, usually I used this through VPN's, and
currently all stored connection has just select privilege - these
are not sensitive datas of course.)
After I get the DB desc, I use "row" SQL connection, eg. when DB
is MySQL, I import the MySQLdb modul, create a mysql connection,
a cursor...
This is different from marketing agencies example, but I can use
the "ultimate" solution at every cases.
Andre Terra
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
