Hi, ro60
There is no need in such setting. Just now you can set table engine to
entire database or in settings.py per-connection with
DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB" }
On Mar 25, 5:37 am, ro60 <[EMAIL PROTECTED]> wrote:
> Wanted to see what everyone thinks about
Another thing, which was solved in my group_by patch, is count()'ing
those rows. I haven't looked at any of the aggregate code but did you
solve that?
Here's the query in Curse's ORM:
MyModel.objects.filter(Q(tags__tag='test') |
Q(tags__tag='test2')).extra(having=['count(1) =
2']).group_by('id')
Distinct can cover most use cases for this, but in general:
MyModel.objects.filter(some_kind_of_manytomany__blah__blah__blah=X).select_related(some_kind_of_manytomany__blah).group_by(some_kind_of_manytomany__blah)
If you tag on anything for an additional select that distinct can't
handle, you nee
On Mon, Mar 24, 2008 at 11:15 PM, Alex P <[EMAIL PROTECTED]> wrote:
> 1. The original message was in brief: there is a growing interest in
> the Python community for DB2 support, and we (developers behind IBM_DB
> driver, DB-API wrapper and SQLAlchemy adapter) are interested to help
> in the D
So, I've worked up a new patch that works for me with manage.py and
django-admin.py both with the settings flag and the environment
variable. The only real difference from the original is that now in
setup_environ, DJANGO_SETTINGS_MODULE is only set if it hasn't been
already. If the DJANGO_SETTING
Not because I'm never going to give up, but because there are 2 points
that needed to be addressed, I am now resurrecting this thread once
more:
1. First, surprisingly but consistently, the message gets
distorted, and for the benefit of the original poster and at least 5
or 6 other Python and
On Mon, Mar 24, 2008 at 10:55:03PM -0500, Jeremy Dunck wrote:
> One other enhancement I thought might be good is to have a
> Model.pre_init signal
Such a signal exists already last I looked, same for post_init...
Please clarify.
> Other similar class-based
> receiver lists might speed things up
Ticket #6814 is working to improve signal performance.
Feature tradeoffs:
Strong/weak receiver connections - strong-only is a big win-- about 2x
performance. Any receivers going out of scope (and not to be called)
should be explicitly disconnected if we remove support for weak
receivers.
.send
Wanted to see what everyone thinks about the idea of adding a patch to
allow for a setting that will automatically append a table engine type
to the create table statements generated by
django.core.management.sql.
I created a patch for my local sql.py and it seems to work well. It
consists of add
On Mon, Mar 24, 2008 at 7:19 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> So we're not going to support group by at all, even though is
> extremely simple? I don't understand why everyone says mine (and
> Curse's and many other peoples) use of SQL is so uncommon. I'd
> guarantee almost ever
On Mon, Mar 24, 2008 at 4:23 AM, Winsley von Spee <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> perhaps I've just read over it, but how to you plan to handle not
> numeric types like datetime? In mysql you have to use something like
> "FROM_UNIXTIME(AVG(UNIX_TIMESTAMP(today))", but how should that be
A quick ping: I've written a small patch against qs-rf which might
facilitate the development of aggregates, and solve David Cramer's
problem of having to fork Django.
The idea is to allow for a custom QuerySet subclass to be used by
default everywhere, so if you subclass
django.db.models.query.
> I wasn't at PyCon, and haven't done any 3.0 porting work myself, so I
> could be behind the times, but my understanding of current porting
> advice (based on PEP 3000) was that it's not going to be possible to
> support 2.x and 3.x from a single codebase in many cases (even with
> 2to3) if
On Mon, Mar 24, 2008 at 5:19 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
>
> On 24 Mar 2008, at 20:48, Rob Hudson wrote:
> >
> > On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
> >>
> >> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]>
> >> wrote:
> >>> Would proposi
I started playing with subclassing the auth models today. What's nice is
that when you subclass User with, say, UserProfile, all users get a
.userprofile property, so the functionality of get_profile() is there for
free with the bonus of multiple User subclasses if that's needed.
I was thinking it
On 24 Mar 2008, at 20:48, Rob Hudson wrote:
>
> On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
>>
>> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]>
>> wrote:
>>> Would proposing a complete replacement be a tad too controversial
>>> for a GSoC
>>> project?
>>
>>
>> Yes
On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> > Would proposing a complete replacement be a tad too controversial for a
> GSoC
> > project?
>
>
> Yes. It also wouldn't succeed as a project, because it's the
On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> Would proposing a complete replacement be a tad too controversial for a GSoC
> project?
Yes. It also wouldn't succeed as a project, because it's the Google
*Summer* of Code, not the Google Several Years of Code.
--
"B
I have been considering Django + SQLAlchemy as a potential summer of
code project. I understand there is a branch which has gone nowhere
and this project: http://code.google.com/p/django-sqlalchemy/
I have read numerous comments on here about either entirely replacing
the current database c
On Mon, Mar 24, 2008 at 10:30 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On Sat, Mar 22, 2008 at 3:04 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> ...
> > On the other hand, all this gymnastic is done to allow receivers which
> > do not conform to the full API of a signal (i.e., does no
I'd venture that it's a simple oversight. items() is likely taking
more memory in addition to being slower because it creates a list of
the items while iteritems simply returns an iterator.
On Mar 24, 9:51 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Ive been having to dig into code vs documenta
Now that we actually have a working patch [1], there are a few details
I'd like to raise here.
Major Issues
===
Supporting dictionaries in form code
While we can have file objects that support the dictionary lookup to
make those backwards compatible, ther
On Mar 23, 7:49 pm, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> At the PyCon sprint, I started porting Django to Python 3.0. In the
> process, I had to make a number of changes to Python, so this port
> currently requires the Python 3.0 subversion head (soon to be released
> as 3.0a4).
...
> a) s
Alex, Antonio, & Leon:
IBM should understand our frustration when a spec exists (in
`django.db.backends`) but, because it is in source code form, your
particular IBM department cannot look at it. Thus, IBM is attempting
to shift the burden onto our community to produce onerous technical
document
This is quite the discussion thread. I was having a hard time trying
to figure out where to insert the post.
Let me introduce myself. I am Leon Katsnelson and I am responsible for
Product Management for the IBM Data Management portfolio which
includes DB2 and IDS database servers as well as Data
On Sat, Mar 22, 2008 at 3:04 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
...
> On the other hand, all this gymnastic is done to allow receivers which
> do not conform to the full API of a signal (i.e., does not accept all
> signal arguments). What is the real reason behind this? Signal
> "exten
I was wary of re-implementing the logic in the test, just because it
makes the test somewhat opaque.
In the end, I added a helper function to clean the path results,
submitted a patch: http://code.djangoproject.com/ticket/6868
--Ned.
http://nedbatchelder.com/blog
Malcolm Tredinnick wrote:
> On
On Mar 24, 10:49 am, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> At the PyCon sprint, I started porting Django to Python 3.0. In the
> process, I had to make a number of changes to Python, so this port
> currently requires the Python 3.0 subversion head (soon to be released
> as 3.0a4).
FWIW, ha
Hi Martin,
Just responding to the pertinent bits. I stand corrected on all the
rest.
On Mon, 2008-03-24 at 11:10 +0100, Martin v. Löwis wrote:
> > Some of the things you've identified as "Django should..." are a little
> > problematic since one of the current requirements (at least for 1.0) is
> Some of the things you've identified as "Django should..." are a little
> problematic since one of the current requirements (at least for 1.0) is
> "Django should work out of the box with Python 2.3". Some of your
> proposed changes don't even work with Python 2.5, so we need to add a
> few
Ive been having to dig into code vs documentation lately, and there
are *tons* of uses of items() vs iteritems(). I was wondering why this
is?
I did a quick benchmark, on an example I found in newforms, to try and
give myself an answer:
In [31]: timeit.Timer("attrs2=attrs.copy();[(field_name,
at
31 matches
Mail list logo
