On Fri, 2007-08-17 at 04:49 +, [EMAIL PROTECTED] wrote:
> I am using mysql as back end,
> i have encoded data stored as
>
> SQL: Insert into test values('919986049773',ENCODE(abc123,
> 'key123')) ;
>
> and to retrive
>
> SQL: SELECT mobnum, DECODE(Password, 'key123') FROM test
>
> Can anyo
> Nathan, perhaps you can post a short excerpt of your code?
>
> Closures are lovely and all, but newforms needs a few minor but
> important design changes so it doesn't require us to do anything even
> slightly hackish. It's close, but no cigar - yet.
I'd be happy to, however if you feel that cl
And I just realized I missed #3134, which argued for a slightly
different solution, in the form of an 'order_by' parameter to the
views.
Personally, I think it's easier to just skip the parameter and rely on
the fact that you can apply whatever ordering you like to the QuerySet
before passing it
After being somewhat startled by the results of the archive_year
generic view and finding that the source of my confusion was an
explicit "order_by()" being done in that view, and finding another in
archive_index, I opened #5188 with a patch which removes these calls
to "order_by()".
I think the
I am using mysql as back end,
i have encoded data stored as
SQL: Insert into test values('919986049773',ENCODE(abc123,
'key123')) ;
and to retrive
SQL: SELECT mobnum, DECODE(Password, 'key123') FROM test
Can anyone help me how to do django db module
object.filter(...)
--~--~-~--~---
> Closures; fantastic. The more I learn about Python the shorter and
> shorter my code gets. :-)
Nathan, perhaps you can post a short excerpt of your code?
Closures are lovely and all, but newforms needs a few minor but
important design changes so it doesn't require us to do anything even
slight
> The solution is that clean_* methods should just be passed the field's
> value as an argument.
> Even being backwards incompatible, I think it needs to be done.
Absolutely, +1 here too. What was the argument against this?
--~--~-~--~~~---~--~~
You received this
On Thu, 2007-08-16 at 22:37 -0400, Marty Alchin wrote:
[...]
> On a related note, if (as I expect would the case here) a patch ends
> up involving multiple tickets, how should that be handled in Trac?
> Just pick one of the tickets that seems most important and go with
> that one? These kinds of r
On 8/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> The stuff I'm doing can safely be ignored because it's an addition on
> top of existing stuff. The reason for this approach is that it's 100%
> backwards-compatible and it doesn't fall into the trap of prematurely
> limiting options -- if
On Thu, 2007-08-16 at 12:39 -0400, Marty Alchin wrote:
> On 8/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
[...]
> There was some discussion a while back[1] about trying to make
> FileField more self-sufficient, but I had been holding off on any of
> that until Malcolm reveals his grand pl
On 8/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm proposing a "--with-fixture" flag to django-admin.py, so that you
> could do something like this:
>
> django-admin.py runserver --with-fixture=mydata.json
I've implemented this in http://code.djangoproject.com/changeset/5912
The do
On Aug 16, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> The current latest patch fails in a dangerous way, which is why I'm
> against it. Fail safely (so that my data always gets saved when I call
> save()) and it's up for consideration.
My changes latest patch ensures it fails safely.
On 8/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Yeah, add me to that list...
>
> I've been toying with the idea of file "backends" -- small modules
> responsible for storing and retrieving files (and their URLs). The
> filesystem backend is the most obvious, but this system could allow
On 8/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Have done; a few smallish changes leading up to [5903].
>
> There were a few small bugs with missing imports; I've also added two
> new base command types to improve error checking:
Excellent -- thanks for making the good changes.
Adri
On 8/16/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Of course, there are those of us who think that should be factored out
> for other reasons anyway. :) I won't spoil this thread with that rant,
> though.
Yeah, add me to that list...
I've been toying with the idea of file "backends" -- small
On 8/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Django committers Down
> Under, feel free to chip in, if you'd like.
Have done; a few smallish changes leading up to [5903].
There were a few small bugs with missing imports; I've also added two
new base command types to improve error ch
On 8/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> If you're going to tackle this issue, keep in mind that the
> infrastructure to save files already exists as part of the
> save_FILE_file() implementation in a model. This would need to be
> factored out to avoid duplication.
Of course,
On 16.08.2007., at 11:42, Gábor Farkas wrote:
> 1. create a non-recursive delete-method (either by adding a
> boolean-argument to Model.delete(), or by creating a new method)
>
> 2. make Model._collect_sub_objects into a documented non-private
> method.
That's a big +1 from me (for what is wor
Related to http://groups.google.com/group/django-developers/msg/
17c957b08d0de8ad but I don't want to hijack Gábor's thread :)
I'm not sure that this is discussed earlier ...
Can we have alternative for the `delete` method which will call
`delete` method (and fire events) from the sub-objects
On 8/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> As of changeset [5898], I've checked in this refactoring.
manage.py startapp doesn't work after update. I've filled ticket
http://code.djangoproject.com/ticket/5179
--
Vsevolod Solovyov
--~--~-~--~~~---~--~--
> I'm not sure I like the idea of specifying a structure for it. I think
> I'd rather see a registration utility like the template library uses,
> so apps could use whatever structure they like,
I'd prefer this too. At there very least, provide the option to manually
register commands as an alter
On 8/16/07, Mads Sülau Jørgensen <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> Perhaps it's just me beeing lazy, but would a .save(path_to_save_to)
> method on a UploadedFile not be quite convienent?
>
> Just wanted to check with you before opening a ticket + patch.
I briefly considered this idea, but I
hi,
when django deletes an object (using the object's delete() method),
then all related objects are also deleted.
this is not always a good thing.
there are various approaches to solve this, like:
http://code.djangoproject.com/ticket/1007
and
http://code.djangoproject.com/ticket/2288
,
but th
Hi.
Perhaps it's just me beeing lazy, but would a .save(path_to_save_to)
method on a UploadedFile not be quite convienent?
Just wanted to check with you before opening a ticket + patch.
--
Mads Sülau Jørgensen
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You re
On 15 Aug., 19:30, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Would it be worthwhile to add a way to purge unused content types via
> manage.py? It could look at INSTALLED_APPS and anything not installed
> it removes?
I have started a tread in django-users a long time ago:
http://groups.google.com/
On Aug 15, 4:44 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I look forward to seeing your patch! :-)
First attempt is in this ticket...
http://code.djangoproject.com/ticket/5177
I do need to test a bit further on a real project and with users who
have permissions to see how it all man
26 matches
Mail list logo
