Re: GSoC: Data importation class

Hi, I see a few problems here. The gist of what follows is that it seems a bit abstract and as one tries to nail down the specifics it either devolves to a more-or-less already solved problem that doesn't require Django core changes, or a problem that is so unconstrained as to not be solvable by

Re: GSoC10 Idea: Additional queryset methods

On Fri, 2010-03-19 at 05:39 -0700, Sh4wn wrote: [..] > I want to refactor the QuerySet and other databases related API's, > which adds an additional method of selecting records, and provides > more control of what data you'll select, but probably is a bit more > complex than the current API. It's

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

On Wed, 2009-08-12 at 20:05 -0700, Kevin Henry wrote: [...] > But if you decide to customize the widget, for example: > > class AuthorForm(forms.ModelForm): > name = forms.CharField(widget=forms.TextInput(attrs={'size':80})) > > class Meta: > model = Author > > the form field

Re: App Engine support

On Wed, 2009-08-12 at 03:04 -0700, Waldemar Kornewald wrote: > On Aug 12, 11:40 am, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: > > On Wed, 2009-08-12 at 02:32 -0700, Waldemar Kornewald wrote: > > > Is there a way to override sql.subqueries? > >

Re: App Engine support

On Wed, 2009-08-12 at 02:32 -0700, Waldemar Kornewald wrote: > On Aug 12, 2:09 am, Russell Keith-Magee > wrote: > > > Is the consensus that further refactoring or rethinking of things like > > > QuerySet and Query are required to make this happen? > > > > Not really a

Re: Change list default sort modification proposal

For those, like me, wondering what this proposal was about, it's concerning changing sorting in the admin interface to initially use the full set of fields specified in Meta.ordering on the model. What I can't work out yet, due to difficulty in reviewing the patch, mentioned below, is whether it

Re: FileFields and file ownership

On Tue, 2009-08-11 at 04:39 -0700, Ole Laursen wrote: > Hi! > > There are a couple of bugs open/closed about what happens when you > upload a new file to a file field that already has a file: > > http://code.djangoproject.com/ticket/11663 > http://code.djangoproject.com/ticket/2983 >

Re: 1.2 Proposal: Database savepoint refactoring

On Tue, 2009-08-11 at 10:21 -0700, Richard Davies wrote: > > I don't agree the current savepoint use within Django is inconsistent. As > > far as I can tell, savepoints are used internally in the one case where > > Django itself catches and suppresses an IntegrityError. > ... > > Right now it is

Re: Online Documentation issues

On Tue, 2009-08-11 at 10:45 +0200, Marc Remolt wrote: > Hi, > > browsing the online docs, I stumbled over two minor issues: > > The online documentation under http://docs.djangoproject.com/en/ still > redirects to http://docs.djangoproject.com/en/dev/, which should be > .../1.1/ I suppose.

Re: App Engine support

On Tue, 2009-08-11 at 00:03 -0700, Waldemar Kornewald wrote: > Hi, > > On Aug 11, 1:55 am, Russell Keith-Magee > wrote: > > > In conclusion, no on is currently working on, but for all the people > > > who seem to ask for this I've seen almost no code written, which > > >

Re: App Engine support

On Mon, 2009-08-10 at 22:31 -0500, Jacob Kaplan-Moss wrote: > On Mon, Aug 10, 2009 at 9:07 PM, Malcolm > Tredinnick<malc...@pointy-stick.com> wrote: > > The only that seems to be possibly *required* to be changed in Django to > > support app-engine as a storage backen

Re: App Engine support

On Tue, 2009-08-11 at 10:58 +0800, Russell Keith-Magee wrote: [...] > This one is slightly topical. Alex has a github branch that refactors > the m2m code to get the SQL out of the related field model [1]. In > order to do this, it introduces a dummy model for m2m fields. This is > needed for

Re: App Engine support

On Mon, 2009-08-10 at 05:19 -0700, Waldemar Kornewald wrote: > Hi, > now that 1.1 is out we can finally discuss App Engine support. Is > anyone planning to work on this feature or working on it for real or > are there just announcements that someone might consider doing it? > > BTW, I've

Re: App Engine support

On Tue, 2009-08-11 at 07:55 +0800, Russell Keith-Magee wrote: > On Mon, Aug 10, 2009 at 10:56 PM, Alex Gaynor wrote: > > > > On Mon, Aug 10, 2009 at 7:19 AM, Waldemar Kornewald > > wrote: > >> > >> Hi, > >> now that 1.1 is out we can finally discuss

Re: Allowing single values instead of tuples for choices in ChoiceField

On Sun, 2009-08-09 at 00:41 -0700, andybak wrote: > It does get slightly uglier when you have cases such as: > f = CharField(choices=zip > (some_complex_expression_that_generates_a_list, > some_complex_expression_that_generates_a_list)) > > You don't really want to assign the expression to a

Re: Allowing single values instead of tuples for choices in ChoiceField

On Fri, 2009-08-07 at 08:37 -0700, gruszczy wrote: > Hi everyone! > > I have created a ticket here: http://code.djangoproject.com/ticket/11644, > but it was marked wontfix and told to ask here about this change. > > The issue is that I consider convenient being able to pass a list of > either

Re: Status

On Fri, 2009-08-07 at 20:17 -0700, Marc Garcia wrote: > Hi Malcolm, > > I thought it didn't make sense to close tickets from commits until > now. You don't close the ticket. You put "Refs" in the commit message and it puts the commit message in the ticket without closing. This is all described

Re: 1.2 Proposal: Add a few more tutorial steps

On Sat, 2009-08-08 at 00:15 +0100, Dougal Matthews wrote: > I'm a +1 for helping and doing whatever I can do improve the tutorials > as I think they could be expanded. However I'm about to bugger off for > a month so I'm not sure how that will fit in with timelines and such. We are thinking of

Re: Logging instead of connection.queries

On Tue, 2009-08-04 at 09:22 -0400, George Vilches wrote: [...] > > Putting signals on a replacement CursorWrapper would give the same > functionality from a user standpoint (the ticket outright says "This > will enable all sorts of interesting and useful things, such as > logging and debugging

Re: Session namespaces

On Tue, 2009-08-04 at 13:36 -0700, veena wrote: [...] > Do you think session namespaces would be useful and should be in > Django 1.2 development roadmap? I honestly can't get that excited about this. You can already use whatever dictionary keys you like now in sessions and if you want to split

Re: [soc2008/i18n] Status

Hi Marc, On Wed, 2009-08-05 at 05:22 -0700, Marc Garcia wrote: [...] > Now, while waiting for feedback, I'll be fixing some minor i18n bugs, > already reported on trac. I assigned to myself, what I plan to work > on, so you can check the list on trac [2]. None ot eh tickets you have currenly

Re: Ticket 10912: Autoescaping variable input in template tags

On Mon, 2009-08-03 at 16:25 -0700, ab wrote: > Is this something that could be backwards-incompatible in 1.2? Please, no. There are thousands of template tags in the wild. This would be a *massive* imposition on existing code. Regards, Malcolm

Re: Logging instead of connection.queries

On Mon, 2009-08-03 at 15:48 +0400, Ivan Sagalaev wrote: > Hello! > > A couple of days ago a sudden thought has struck me while thinking on > the matter of logging in Python libraries. I consider a good practice > for a library to log what it's doing into a named logger without setting > up

Re: Long-term direction for shortcuts

On Mon, 2009-08-03 at 10:06 +0400, Ivan Sagalaev wrote: > Brent Hagany wrote: > > The issue of making shortcuts better (and decreasing the number of > > imports in views.py files) was brought up at DjangoCon > > Another angle on the issue of reducing imports is that we can do it not > with

Re: Long-term direction for shortcuts

On Sun, 2009-08-02 at 18:53 -0700, chairface wrote: > On Aug 2, 8:36 pm, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: > > On Sun, 2009-08-02 at 18:05 -0700, Brent Hagany wrote: > > > > Putting too much weight on more or less throwaway comments in

Re: Long-term direction for shortcuts

On Sun, 2009-08-02 at 18:05 -0700, Brent Hagany wrote: [...] > If you watch the video, there was some disagreement with the idea > right from the start. Putting too much weight on more or less throwaway comments in a single video isn't going to be particularly useful. > The ticket that grew

Re: Ticket 10912: Autoescaping variable input in template tags

On Sat, 2009-08-01 at 12:17 +1000, Malcolm Tredinnick wrote: > Hi Andrew, > > On Fri, 2009-07-31 at 15:44 -0700, ab wrote: > > When a template tag takes a variable as input and renders its value > > (like the `cycle` or `firstof` tags), that value should respect the >

Re: Ticket 10912: Autoescaping variable input in template tags

Hi Andrew, On Fri, 2009-07-31 at 15:44 -0700, ab wrote: > When a template tag takes a variable as input and renders its value > (like the `cycle` or `firstof` tags), that value should respect the > context's autoescape setting. Right now, the values are never escaped. > I'm proposing to make

Re: Encodings outside of utf-8

On Wed, 2009-06-17 at 15:54 -0500, Jeremy Dunck wrote: > On Wed, Jun 17, 2009 at 3:50 PM, ccahoon wrote: > ... > > > > Does anyone have a use-case they could share with me? > > > > I hear Malcolm's hovercraft is full of eels. For those wondering if Jeremy might have lost

Re: Localization of permissions names

On Wed, 2009-05-13 at 13:14 -0700, hcarvalhoalves wrote: > I tried both reopening [1] and filling a new ticket [2], but looks > like I'm doing it the wrong way as they kept being closed. So here I > come asking for help on the list. The reason in both cases was explained in the tickets (and in

Re: DatabaseWrapper operators

On Mon, 2009-05-04 at 03:26 -0700, pbzRPA wrote: > I would like to know if anyone knows how to create custom operators > for querysets. > > Currently you can do something like: > > foo.objects.filter(myfield__icontains = x) > > I would like to add my own operator so I can do something like: >

Re: Multi-DB Update

On Fri, 2009-05-01 at 08:47 -0700, codysacoder wrote: > Why not allow both to work (parse the DSN string if encountered)? That should be an option of last resort. One way to do things, preferably obvious, even if you're not Dutch, and all that jazz. I'd prefer dictionaries to strings, because

Re: GSoC Status update (week 2) - HTTP & WSGI Support

On Fri, 2009-05-01 at 13:09 -0600, Brian Rosner wrote: > On Fri, May 1, 2009 at 12:10 PM, ccahoon wrote: > > I have also been looking in to how I want to do revision control > > locally. After playing around with various systems, I think I've > > settled on Git. Does

Re: Week 2 Status and Info

Trimming the reply list a fair bit, since all the individual CC'd people are already on django-dev. On Fri, 2009-05-01 at 11:46 -0600, Kevin Kubasik wrote: > Hey, so its Week 2 of the 'get to know things and people' phase, and > things are going well. Here's a request for, I guess, everybody

Re: SQL Anywhere database backend

On Tue, 2009-04-28 at 14:38 -0400, Nathan Auch [Sybase] wrote: > Hi Russ, > > Thanks for taking the time to respond. We will finish off the SQL > Anywhere work in Django and then follow the procedure you outlined. It > sounds like starting with a externally maintained module and seeing >

Re: [GSOC] Multi-DB

On Tue, 2009-04-21 at 16:36 -0400, Alex Gaynor wrote: > > > On Tue, Apr 21, 2009 at 4:29 PM, Malcolm Tredinnick > <malc...@pointy-stick.com> wrote: > > On Tue, 2009-04-21 at 15:46 -0400, Alex Gaynor wrote: > > > > >

Re: About localization settings

On Tue, 2009-04-21 at 01:47 -0700, Fidel Ramos wrote: > On Apr 21, 12:04 am, Marc Garcia wrote: > > just to warm up for my Google Summer of Code on i18n, I want to start > > a discussion on to simple things... > > I'm glad to see something is going to finally get done in

Re: [GSOC] Multi-DB

On Tue, 2009-04-21 at 12:14 -0700, Malcolm Tredinnick wrote: > On Tue, 2009-04-21 at 13:45 -0400, Alex Gaynor wrote: [...] > > 1) Make sure absolutely no tests are done against self.connection > > before the SQL is actually sent to the database(currently this occurs > &

Re: [GSOC] Multi-DB

On Tue, 2009-04-21 at 13:45 -0400, Alex Gaynor wrote: > Hello All, > > As you know by now I've been selected to work on multiple database > support in Django as a part of the Google Summer of Code. I'm going > to try to keep this brief as a) not much of my API thoughts have > changed since my

Re: Adding a signal to indicate when all models have finished loading. (#7538)

On Fri, 2009-04-10 at 12:51 -0700, polarc...@gmail.com wrote: > I'd like to get get discussion started on the introduction of a "all > models loaded and ready for use" signal within AppCache. There's a > ticket already out there for this (http://code.djangoproject.com/ > ticket/7538) but it looks

Re: Possible Q() bug, duplicate where clause

On Thu, 2009-04-09 at 20:48 -0700, jameslon...@gmail.com wrote: > I have a dynamically generated search form which constructs Q() > objects at runtime. This works brilliantly in almost every case. There > is a particular combination of these objects which appears to create > an extra where clause

Re: Why hardcoded unique and db_index?

On Thu, 2009-04-09 at 14:31 -0700, Adys wrote: > http://groups.google.com/group/django-developers/browse_thread/thread/87aae5cbd60bb904/505f3bd962711db7?hl=en > > You wanted an use case, someone else just provided you with it. No they didn't. There's still an unanswered request in that thread

Re: add_constraint=False on relation fields

On Mon, 2009-04-06 at 04:53 -0700, Adys wrote: > I made a small patch for my local Django install to be able to precise > add_constraint=False (default True, normal behaviour) to FKeys/ > M2Ms/... > As the tin says, it prevents index/constraint creation for that field. > I won't bother going

Re: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

On Sun, 2009-04-05 at 22:44 -0400, Alex Gaynor wrote: [...] > > To be clear(since I most certainly wasn't before). I'm not > necessarily advocating that idea, merely saying that it's a false > dichotomy to say he have to pick only one way, we merely need to > provide the default behavior. No,

Re: MySQL test failure

On Sat, 2009-04-04 at 01:21 -0400, Daniel Tang wrote: [...] > Not sure if this is an end-all solution, but you can pass a > client_flag kwarg that makes MySQLdb return the number of matched rows > instead of affected rows. In MySQLdb.constants.CLIENT there is a > FOUND_ROWS constant. Passing it

Re: MySQL test failure

On Fri, 2009-04-03 at 21:56 -0500, Jacob Kaplan-Moss wrote: [...] > > File > "/var/buildbot/slave/parts/ubuntu-8.04-python2.4-mysql5.0/django-trunk_ubuntu-8.04-python2.4-mysql5.0/build/tests/regressiontests/model_inheritance_regress/models.py", > line ?, in

Re: A bunch of little fixes

On Fri, 2009-04-03 at 17:50 +0200, Raffaele Salmaso wrote: > * add app_label name to related_name > http://code.djangoproject.com/ticket/9638 [... etc, etc...] What are you wanting to achieve here? Are some of these actual bug fixes (as opposed to feature enhancements) that are not already in

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 17:31 -0700, Bill Konrad wrote: > First off, thanks for taking the time to read through it and give so > much feedback. > > Please let me clarify one thing. If you read the above as a proposal > than it wouldn't have seemed much like a proposal. I was only > outlining

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 15:36 -0700, Bill Konrad wrote: > Ivan, > > Thanks for the quick feedback. What I meant by predictable (and maybe > it's the wrong word in this case) is that when assigning a URI to a > resource, a convention is followed, not that the user can "predict" > the URI itself.

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 14:35 -0700, bkonrad wrote: > I was fortunate enough today to have a quick chat with Jacob Kaplan- > Moss about the concept of a generic REST API module for Django. We > spoke about how this has been attempted before and some of the > remaining issues that still require

Re: Deletion of related objects

On Tue, 2009-03-31 at 14:48 -0500, Jeremy Dunck wrote: > Malcolm, Jacob pointed me at you, since the code in question was a > commit around QSRF-time. > > I'm aware of ticket #7539, but would prefer to keep the scope narrower > and ask the hopefully-useful question-- is #9308 a bug? If so, I'd

Re: Signals sent by the cache framework?

On Sun, 2009-03-29 at 17:15 -0700, Oliver Beattie wrote: > I figured that might be the case. I am wrapping the backend now in > tests, I just hate monkey patching :) There should be no monkey-patching involved. Using a separate settings file for tests so that it points to its own cache isn't

Re: Signals sent by the cache framework?

On Sun, 2009-03-29 at 16:28 -0700, Oliver Beattie wrote: > Hey Everyone, > > I just wanted to poll opinion on a feature request I'm considering > posting a ticket for (and obviously write a patch for). Basically, I > want the cache framework to send signals whenever it interacts with > the cache

Re: Dynamic urlconf

On Sun, 2009-03-29 at 16:06 -0500, Jeremy Dunck wrote: > I have a need for dynamic URL definition, but I see that > RegexURLResolver.reverse uses a cache, _reverse_dict. > > Option 1): >Make a RegexURLResolver subclass which sets _reverse_dict back to > an empty MultiValueDict when a URL is

Re: How to set the CURRENT_TIMESTAMP in a datetime field

On Fri, 2009-03-27 at 03:58 -0700, PyMan wrote: > Hi all guys. > > I tried to look for around a way to set a datetime field with the > CURRENT_TIMESTAMP value. I found nothing useful. Did I miss anything? You missed that this list is for the development of Django itself, not "how can I..."

Re: An idea (with full patch) for enhancing Meta.permissions behavior

On Fri, 2009-03-27 at 13:57 -0700, faldridge wrote: [...] > Though a small change, this is definitely one that requires a design > decision. I would greatly appreciate it if someone with authority > would let me know whether I should open a ticket for this patch or > not, and/or make any

Re: [GSoC] Proposal for discussion about Serialization requirements and requesting for Review

On Fri, 2009-03-27 at 00:23 +0530, Madhusudan C.S wrote: > Hi all, > > What a blunder :( I submitted my proposal the way I will > have to submit to socghop.appspot.com with lines manually wrapped > at 80 chars per line and the groups wrapp it at 75 chars making > my proposal look as ugly as

Re: Killing reloaders when parent receives TERM signals

On Thu, 2009-03-26 at 21:58 +, Chris Lamb wrote: > Malcolm Tredinnick wrote: > > > The development server is intended for single user, simple development > > stuff. It runs as a foreground process and ^C stops it very nicely. > [..] > > The goal is, intentional

Re: Killing reloaders when parent receives TERM signals

On Tue, 2009-03-24 at 15:27 -0700, Dave Benjamin wrote: > No, I'm trying to run it as a dev server. I use mod_python in > production. However, I use the dev server in a shared environment so > that a few other programmers and testers in the office can view the > site. > > In any case, sending a

Re: Flatpages has been broken by a recent change (10139)

On Tue, 2009-03-24 at 07:06 -0700, Stephane Raimbault wrote: > The following changeset has broken the flatpages feature: > http://code.djangoproject.com/changeset/10139 > > I can't access the flat page list (admin/flatpages/flatpage/) with > this change (error on f.rel.get_related_field().name).

Re: select_related to work with backward relationships?

On Mon, 2009-03-23 at 21:45 -0400, George Vilches wrote: > > On Mar 23, 2009, at 8:08 PM, Malcolm Tredinnick wrote: > > > It is documented in that respect. In a couple of different Trac > > tickets > > (since there are multiple issues: select related for reverse

Re: DDN on #9284

Hey Joseph, On Mon, 2009-03-23 at 15:32 -0500, Joseph Kocherhans wrote: > #9284 [1] Has a patch to make BaseModelFormSet call ModelForm.save() > when saving objects rather than using completely custom code as it > does now. I think this is the "right thing (tm)" to do, but it will > break

Re: select_related to work with backward relationships?

On Mon, 2009-03-23 at 06:50 -0700, Jari Pennanen wrote: > Found out that it doesn't work. > > I think this should be documented that backwards relationships does > *not* work in select_related, since I see no reason why it couldn't > work, it might be tricky to implement, but I think it should

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Mon, 2009-03-23 at 10:44 +0300, Ivan Sagalaev wrote: [...] > A person there wanted an `update()` method too but not behaving like you > show. Instead he wanted it to update *just* the fields passed as > arguments. I.e. it should be equivalent to this: > > def update(self, **kwargs): >

Re: [GSoC] Ticket #5929 (Previously Serialization Refactor)

On Sun, 2009-03-22 at 14:07 +0530, Madhusudan C.S wrote: [...] > > To be very frank I haven't myself come up with anything > concrete till now, since the ideas list themselves don't > tell anything in specific, but just give a hint to what > might be lead to a potential GSoC project.

Re: %ifequal - what am I missing here?

On Sun, 2009-03-22 at 18:06 -0700, nwalt...@sprynet.com wrote: > I'm trying to compare the current user logged on to user stored in the > database (using GAE - Google App Engine). > > Here are my four attempts so far and their results: > > 1) {%ifequal conference.userAdded user.email %}

Re: auto_now = True - only on some updates

On Sun, 2009-03-22 at 17:23 -0700, nwalt...@sprynet.com wrote: > I have a table where users can add their own rows, but the admin must > approve it. > So my model contains this: > dateAdminDecision = db.DateTimeProperty(auto_now=True) > > Obviously, at first, every row, even when the users

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Sun, 2009-03-15 at 12:44 -0700, Dan Watson wrote: > On Mar 15, 1:12 pm, "Gary Wilson Jr." wrote: > > What do you think? > > Wouldn't this be a backwards-incompatible change at this point? It > would clash with any model fields named "update". No, because of a

Re: [urls bug?] django calls several views at once.

On Sat, 2009-03-21 at 23:18 -0700, igor.potapenko wrote: > Is it normal behavior? > In example below, I try to call myapp2.view.cat2_view through "/a/" > url-path. It's calling, however another views myapp1.view.cat1_viewis > also calling with it at same time. Django doesn't call more than one

Re: [GSoC] Ticket #5929 (Previously Serialization Refactor)

On Sat, 2009-03-21 at 23:16 +0530, Madhusudan C.S wrote: > Hi Malcolm and all, >Doesn't ticket #5929 (http://code.djangoproject.com/ticket/5929) > look very similar to what I proposed for Python? Allowing Python > built in complex datatype objects to be mapped to Relational > Database (which

Re: defer() and only()

On Sat, 2009-03-21 at 13:09 +0300, Ivan Sagalaev wrote: > Hello everyone! > > Just played with new defer() and only() and noticed that fields deferred > with only() aren't loaded when asked explicitly. I.e.: > > a = Article.objects.defer('text')[0] > a.text # <-- does a new query as

Re: [GSOC] Multiple Database API proposal

On Sat, 2009-03-21 at 00:41 -0400, Alex Gaynor wrote: > > > > One suggestion Eric Florenzano had was that we go above and > beyond > > just storing the methods and parameters, we don't even > excecute them > > at all until absolutely necessary. >

Re: [GSOC] Multiple Database API proposal

Trimming unused portions of the response to make it readable (which I should have done the first time around, too)... On Fri, 2009-03-20 at 23:41 -0400, Alex Gaynor wrote: > > > On Fri, Mar 20, 2009 at 11:21 PM, Malcolm Tredinnick > <malc...@pointy-s

[Fwd: Re: [GSoC] Serialization Refactor]

Whoops... hadn't noticed this was sent to multiple lists, so only replied to the first one. Sending my technical discussion reply to django-dev, since that's where the main audience participation is likely to be. Forwarded Message From: Malcolm Tredinnick <malc...@poi

Re: IPAddressField

On Mon, 2009-03-16 at 13:18 +0100, Gregor Kling wrote: [...] > Generally i do agree with the *usefulness* of not breaking compatibiltiy. > But on the other hand, I think that correcting this weird handling of IP > addresses would legitimate the cut. > Because the handling of IP addresses is not

Re: [GSOC] Multiple Database API proposal

On Fri, 2009-03-20 at 09:45 -0400, Alex Gaynor wrote: > Hello all, > > To those who don't me I'm a freshman computer science student at > Rensselaer > Polytechnic Institute in Troy, New York. I'm on the mailing lists > quite a bit > so you may have seen me around. > > A Multiple Database API

Re: QuerySet.values() Shallow Copy

On Fri, 2009-03-20 at 05:08 -0700, Vitaly Peressada wrote: > @Malcolm: > > I agree with you that there are some holes in code - it was a quick > hack to solve issue at hand. I did suspect that there should be some > effort to implement this feature and tickets quoted confirm that. It > is too

Re: Url tag and context variables (Re: #7917)

On Thu, 2009-03-19 at 19:30 -0700, Ulrich Petri wrote: > Hi, > > since #9666 (SSI-tag variable resolving) got accepted by Jacob lately > I would like to restart discussion about the same functionality for > the url template tag (as was already proposed in #7917). > > Pro arguments: > - The url

Re: QuerySet.values() Shallow Copy

On Thu, 2009-03-19 at 05:17 -0700, Vitaly wrote: > I wanted json serialize a tree of django model objects: Schedule -> > Player -> django.models.User. > django.core.serializers.serialize does shallow serialization of > QuerySet but I want a deep one. Next, I looked at QuerySet.values() > plus

Re: QuerySet.values() Shallow Copy

On Wed, 2009-03-18 at 17:59 -0700, Vitaly wrote: > I am using django version 1.0 and ran into shallow copy limitation of > QuerySet.values() where it returns ints for ForeignKey columns. Here > is my take on deep copy implementation. Instead of leaping right into a proposed solution, can you

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Sun, 2009-03-15 at 23:11 -0500, Gary Wilson Jr. wrote: > On Sun, Mar 15, 2009 at 4:40 PM, Malcolm Tredinnick > <malc...@pointy-stick.com> wrote: > > On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote: > >> Another option would be to allow Model.update() to

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote: [...] > Another option would be to allow Model.update() to take the > force_update and force_insert parameters that save() does and just > pass these through to the save() call. Aside from the fact that I dislike the ideal as a whole (see

Re: Return value from update()

On Sat, 2009-03-14 at 16:36 +1100, Malcolm Tredinnick wrote: [...] > > I understand what you're saying here, though, so it might not be easy. > I'll think about it a bit, but I'd like to make that return value > meaningful on all backends. Just about to run out the door and I'l

Re: Return value from update()

Hey Russ, On Sat, 2009-03-14 at 14:10 +0900, Russell Keith-Magee wrote: > Hi all, > > [9967] introduced a failure into the test suite, highlighting either > an error in the documentation, or a potentially nasty problem that > requires fixing. > > According to the docs[1] : > > "The update()

Re: Call for review: #689 - REMOTE_USER authentication

On Thu, 2009-03-12 at 17:50 +1100, Malcolm Tredinnick wrote: > Hey Gary, > > On Thu, 2009-03-12 at 01:40 -0500, Gary Wilson Jr. wrote: > > Just posted an updated patch: > > > > http://code.djangoproject.com/attachment/ticket/689/689.4.diff > > If nobody

Re: Proposal: New transaction API with multiple databases

On Sat, 2009-03-14 at 19:52 +1930, qwerty wrote: [...] > What about having an attribute in the Meta class of the model that > let's the model have a default connection for executing the 4 most > common different operations in each conneciton, something like > > class MyModel(models.Model) >

Re: Call for review: #689 - REMOTE_USER authentication

Hey Gary, On Thu, 2009-03-12 at 01:40 -0500, Gary Wilson Jr. wrote: > Just posted an updated patch: > > http://code.djangoproject.com/attachment/ticket/689/689.4.diff If nobody gets to it beforehand, I'll give this a serious look tomorrow. Cheers, Malcolm

Re: django.db.backends refactored; hacks and third-party backends might break

On Tue, 2009-03-10 at 22:54 -0500, Adrian Holovaty wrote: [...] > The full changeset is here: http://code.djangoproject.com/changeset/10026 > > It's a pretty straightforward refactoring, but if you have any > technical questions on how to upgrade third-party backends or your own > hacks, please

Re: Thread-safety bug in WSGIHandler

On Tue, 2009-03-10 at 10:30 -0400, Travis Terry wrote: [...] > So, my proposed fix is to add a flag in WSGIHandler and then test for > that flag in __call__(). Preferable to construct the list as a local variable and then assign it to the attribute in a single instruction. Assignment is

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

On Tue, 2009-03-10 at 12:21 -0500, Adrian Holovaty wrote: [...] > One ugliness about this is that it has to monkeypatch the settings > file in order to change the DATABASE_NAME, before passing it to > DatabaseWrapper._cursor(). So my proposal is to change > DatabaseWrapper._cursor() to accept a

Re: TimeField broken in Oracle

On Tue, 2009-03-10 at 14:19 +1100, Malcolm Tredinnick wrote: > On Mon, 2009-03-09 at 15:46 -0600, Ian Kelly wrote: [...] > > There may also be an argument for removing the seemingly redundant > > get_db_prep_save call from save_base. > > Which would break large amounts of

Re: TimeField broken in Oracle

On Mon, 2009-03-09 at 15:46 -0600, Ian Kelly wrote: > After r10003, Model.save() raises an error in Oracle if the model > includes a TimeField. The reason appears to be that save_base calls > TimeField.get_db_prep_save prior to passing the value on to the > queryset, which calls

Re: 'week_day' starting with sunday as first day of a week need to be fixed

This is getting ridiculous. On Mon, 2009-03-09 at 03:20 -0700, Semmel wrote: > On Mar 6, 7:24 am, Russell Keith-Magee wrote: > > Both options are supported _in many cases_. Not _all_ cases. The > > Sunday=1 case is supported by all the backends. > > Imho that's no real

Re: Declarative fixtures for django

Hey Ben, I don't have a lot (well, any) time to really give this the attention it deserves at the moment. But a couple of quick thoughts so that you don't think it's been entirely overlooked. I agree with the general thrust of what you're talking about and it's good to see questions about

Re: form action="."

On Sun, 2009-03-08 at 03:37 -0700, rihad wrote: > Chapter 7 of The Django Book says this: When the updated version of Chapter 7 of the django boook is released online, if the same description persists, it would be worth making a comment over there. Although the book is written by two of the

Re: [PATCH] Trivial typo in testing documentation

On Sun, 2009-03-08 at 15:20 +1100, Matt Doran wrote: > Thanks Malcom. > > Will do. I saw the patch contribution guidelines, but wasn't sure if > a ticket was required for such a trivial patch. Definitely. The reason isn't because we're complete bastards and like making people do work. It's

Re: [PATCH] Trivial typo in testing documentation

On Sun, 2009-03-08 at 14:19 +1100, Matt Doran wrote: > Hi all, > > Attached is a trivial patch for a typo in the testing documentation. Thanks for this. Best place to file patches is in the ticket tracking system so that they don't get forgotten. http://code.djangoproject.com/simpleticket

Re: Work on #9964

On Sat, 2009-03-07 at 21:24 +0200, Shai Berger wrote: > Hi list, Malcolm, > > If I start working on a patch for #9664 (Transaction middleware closes the > transaction only when it's marked as dirty; marked for milestone 1.1), will I > be duplicating effort? > > The solution I would propose

Re: Proper documentation of Ticket #4140: "manage.py syncdb fails with ORA-06552 when a fieldname is a keyword"

On Wed, 2009-03-04 at 08:20 -0800, boyombo wrote: > I encountered the issue written about in Ticket #4140 while deploying > an application on oracle. I later found that the problem stemmed from > me using field name 'date', which is a keyword, in some of my models. > I did my development on

Re: #3461 'DatabaseWrapper should pass through args and kwargs to underlying database adapter'

On Wed, 2009-03-04 at 18:36 -0200, Ramiro Morales wrote: > Hi all, > > I'm working on fixing and updating the patch for this ticket and found that > neither cx_Oracle nor pysqlite2/sqlite3 connection cursor() methods take *args > and **kwargs parameters. > > Further research shows that the same

  1   2   3   4   5   6   7   8   9   10   >