Re: multiple levels of join
On Jan 12, 2006, at 5:38 AM, Adrian Holovaty wrote:
On 1/11/06, Cheng Zhang <[EMAIL PROTECTED]> wrote:
class Entry(meta.Model):
submission_user = meta.ForeignKey(users.User)
class Friend(meta.Model):
myself = meta.ForeignKey(users.User, related_name="myself",
verbose_name="myself")
friend = meta.ForeignKey(users.User, related_name="friend",
verbose_name="friend")
How may I get a list of entry whose submission_user is in my friend
list, which is myself == my_id?
You can do it in two queries:
my_friends = friends.get_list(myself__exact=my_id)
entries.get_list(submission_user__in=[f.id for f in my_friends])
Adrian
Ya, that's Django's 101. I should be more specific that I'd like to
do it with only one get_list() call.
With the help on IRC, I learned how to use where/table to do this.
entries.get_list(**{'tables' :['friends',], 'where' :
['friends.friend_id = entrys.submission_user_id AND friends.myself_id
= my_id']})
- Cheng
Workflow
Hello, a simple question for the experts: if I need a publishing workflow (usual stuff: author, editor, approver, etc. etc.) within a Django app, I've to build everything from scratch or I've some library helper? Thanks for your time. Ciao. Marco. Time: the only thing that taken up can't be returned...
Re: application level settings
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 1/11/06, Colleen Owens <[EMAIL PROTECTED]> wrote:> My latest question - I want to have some settings that apply to an> application (not the objects within that application's model but to the > application as a whole). For example, I want to have options like the> maximum number of objects that should be displayed and various display> options that are set by the system administrator through the admin > interface. I know I can do this by writing some basic Python code and a> custom view for the admin interface. This seems like a more general problem> though, so I was wondering if Django has some built-in way of handling this. Hey Colleen,I'm not sure this answers your question, but feel free to make up yourown settings. See the docs here: http://www.djangoproject.com/documentation/settings/#creating-your-own-settingsAdrian This isn't exactly what I'm looking for. This would work, but it doesn't seem very elegant. I want the administrator of this site to be able to modify nearly everything through the admin interface. At the moment, I'm thinking about just creating a Configuration class for my app (and forcing it to be a singleton) and storing that in the database. This still feels a little clumsy, but I think it will work. Colleen
Re: Duplicate object
Adrian Holovaty wrote: > On 1/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > >>On Jan 12, 2006, at 8:09 AM, Simon Willison wrote: >> >>>Maybe it would be useful for all Django model objects to gain >>>themselves a duplicate() method which does exactly this - returns >>>an identical object but with id set to None. >> >>+1 -- obj.copy() might be a better syntax to mimic dict.copy(). > > > obj.copy() would be a nice addition, but would it also copy the values > of many-to-many relationships? Like, if a poll is on multiple sites, > would poll.copy() return an object with the sites set? > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com | chicagocrime.org > Also, given that ForeignKeys atm always cause deletion of linked objects, this implies some form of ownership, which might lead people to think that this was going to duplicate 'owned' objects...
Re: How are default values for fields used
akaihola wrote:
Ok, I'll take a look at the _pre_save() mechanism. By the way, isn't
that one of the things changing in magic-removal branch?
Yes, it goes away. Instead one would be able to override save() and do
everything in it.
I still wonder about the default values question though.
I tried to create a Django object in an interactive Python shell, and
the fields are indeed filled with default values. So somewhere in the
form/manipulator mechanism there are unnecessary checks which prevent
this from happening and raise errors instead.
Indeed, default values are set upon model object creation. This is good
:-). But a manipulator doesn't prevent them in any way. What happens is
that a manipulator checks the values that come from the web, and not the
default ones inside it.
To make it work as expected you do something like:
m=someitems.AddManipulator() # or someitems.ChangeManipulator(id)
data=m.flatten_data() # this returns object's data suitable for
rendering on the web including default values
f=formfields.FormWrapper(m, data, {}) # form gets values from this
'data' parameter
And then you form will be prefilled. And you can feed these values to
the saving manipulator on POST
Now that makes me wonder why data is passed to a form separately from
manipulator which has it anyway...
Re: Postgre's with Django Model
I see. I'll try to work around it somehow. Thanks, Mike
Re: Duplicate object
On 1/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On Jan 12, 2006, at 8:09 AM, Simon Willison wrote: > > Maybe it would be useful for all Django model objects to gain > > themselves a duplicate() method which does exactly this - returns > > an identical object but with id set to None. > > +1 -- obj.copy() might be a better syntax to mimic dict.copy(). obj.copy() would be a nice addition, but would it also copy the values of many-to-many relationships? Like, if a poll is on multiple sites, would poll.copy() return an object with the sites set? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: How are default values for fields used
It seems that _pre_save() is never called if the manipulator catches missing fields. So customizing the manipulator seems to be my quick fix after all. I also checked the manipulator objects' attributes, and default values defined in models don't even end up there. So it might require quite a few changes to have the object save functionality work as I vision. One more thought: In RDBM world, a DEFAULT attribute for a column makes the database engine fill in default values whenever fields are missing from INSERT statements. So it would be kind of intuitive to do the same wrt Django manipulators.
Re: Django and MS SQL
Jeremy Dunck wrote: > On 1/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > think adodbapi DOES use parameterization. It's just slightly > > non-standard. (thus, the %s -> ? stuff above) > > I was surprised by this, by the Python DB API allows for parameters in > the string supplied to the provider, and makes it provider-specific. > So it's not non-standard, it's just a surprise. ;-) Correct...it's definitely within the standard. I misspoke; maybe "less than optimal" would have been a better term? *grin* Note I'm a big fan of adodbapi, though...I use it all the time at work for SQL Server utilities. Good stuff. I've been bitten myself before by the limitation of only qmark-style parameters, though; in porting some Oracle monitoring stuff, I had to do a bit of the find-and-replace myself!
Re: How are default values for fields used
Ok, I'll take a look at the _pre_save() mechanism. By the way, isn't that one of the things changing in magic-removal branch? I still wonder about the default values question though. I tried to create a Django object in an interactive Python shell, and the fields are indeed filled with default values. So somewhere in the form/manipulator mechanism there are unnecessary checks which prevent this from happening and raise errors instead. I'd like to research and maybe make a patch for this unless the current behavior is intended with a good reason.
Re: global class Category
On 12 jan 2006, at 15.40, Grigory Fateyev wrote: Hello! In my project need lots of time to create class Category for any apps (news, faq, clubs) and now whant to create global class Category that will many-to-one for other classes. How this class can be done? Put your Category model in a separate app. And then have a look at http://www.djangoproject.com/documentation/db_api/#relationships- across-applications for how joins work across applications. - Daniel
Re: Django and MS SQL
On 1/12/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On 1/12/06, Rich Bakos <[EMAIL PROTECTED]> wrote: > > The pymssql driver only supports DB-LIB, which is way outdated and you > > wont have access to functionality added to MSSQL after version 6.5. > > This is not the best option IMHO. > > Adapter class over adodbapi where supported, falling back to pymssql? I think that may be the best option unless someone wants to write a wrapper for freetds. I tried that using swig before... it didn't work so well, but then again, I'm not that good with C. Another (probably the most stable and documented) option is mxODBC (+freetds on *nix), which unfortunately isn't free... but then again, neither is MSSQL ;) Joseph
Re: Django and MS SQL
On 1/12/06, Rich Bakos <[EMAIL PROTECTED]> wrote: > The pymssql driver only supports DB-LIB, which is way outdated and you > wont have access to functionality added to MSSQL after version 6.5. > This is not the best option IMHO. Adapter class over adodbapi where supported, falling back to pymssql?
Re: Duplicate object
On Jan 12, 2006, at 8:09 AM, Simon Willison wrote: Maybe it would be useful for all Django model objects to gain themselves a duplicate() method which does exactly this - returns an identical object but with id set to None. +1 -- obj.copy() might be a better syntax to mimic dict.copy(). Jacob
Re: Duplicate object
Simon Willison wrote: Maybe it would be useful for all Django model objects to gain themselves a duplicate() method which does exactly this - returns an identical object but with id set to None. There is still complication for non autofield primary key. And it's just 3 lines or under. -- dsw
global class Category
Hello! In my project need lots of time to create class Category for any apps (news, faq, clubs) and now whant to create global class Category that will many-to-one for other classes. How this class can be done? Or this is not good idea? -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
Re: Duplicate object
On 12 Jan 2006, at 05:43, Eric Walstad wrote:
The following approach ('shallow' copy) has worked well for me:
import copy
b = copy.copy(a)
b.id = None
b.save()
Maybe it would be useful for all Django model objects to gain
themselves a duplicate() method which does exactly this - returns an
identical object but with id set to None.
Cheers,
Simon
Re: Django, mod_python error
>> have you created any models in ~/models/resumes.py? Yep, I have a Resume model in /modes/resumes.py
Re: multiple levels of join
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED] > wrote: > > You can do it in two queries: > > my_friends = friends.get_list(myself__exact=my_id) > entries.get_list(submission_user__in=[f.id for f in my_friends]) If you are using the magic-removal branch, there is an alternative approach that only requires a single database query. Using the __ relation walking notation, you can query across relations: entrys.get_list(submission_user__friend__myself__id__exact=my_id, distinct=True) The distinct is required because the join over the reverse direction of the ForeignKey can will yield a duplicate for each Friend of the Submission_User that matches the criteria. Russ Magee %-)
Re: How are default values for fields used
akaihola wrote: So, if I'm not mistaken, the default values for a model's fields are not used when saving an object, They are used to prefill form elements in the Admin (don't know about custom forms though, never tried). So it's just a hint for the user. and I must create a custom manipulator to do that. Not necessarily. It's more convinient to override _pre_save() method in your model and fill default values there.
How are default values for fields used
In the admin interface, I can't omit fields from "admin = meta.Admin(fields=...)" even if they do have default values. If I do that, I get errors for required fields. In my own forms, I first assumed I could just leave out fields with default values in the model, but my form.error_dict gets filled with complaints of missing required values. I don't want the default values to go through the form as hidden fields. So, if I'm not mistaken, the default values for a model's fields are not used when saving an object, and I must create a custom manipulator to do that. But is there a reason why this isn't the current behavior?
