hat can be done without too much
code duplication.
I had another idea for optimistic locking: why not use the pre_save
signal for this? There is a proof of concept how to do this in
https://github.com/akaariai/django_optimistic_lock
The idea is basically that if you add a OptimisticLockField to you
On Aug 8, 6:30 pm, Steven Cummings wrote:
> For backward compatibility, there may be a Model sub-class that would leave
> Model alone altogether (this was suggested on the ticket). This seems fair
> since many seem to be getting by without better optimistic concurrency
> control from Django's ORM
On Aug 8, 4:54 pm, Steven Cummings wrote:
> Interesting feature I hadn't noticed in memcached. That does seem like it
> would do the trick where memcached is being used. I think the ability to
> control it in Django would generally still be desirable though, as that is
> where the data ultimately
Just a quick note: It could be a good idea to have concrete_fields in
addition to virtual_fields in the Meta class. Concrete fields would be
the fields having a database column directly attached to it, the rest
would be in virtual fields. The fields attribute would be these two
joined together. Thi
On Jul 20, 4:18 pm, Michal Petrucha wrote:
> The last week I've been looking into related fields and all that
> stuff. As it turns out, the issue is much more complex than I
> originally anticipated and at the moment I have some doubts whether
> this can be achieved as part of this GSoC.
>
> Basic
On Jul 12, 12:28 pm, Jannis Leidel wrote:
> Yeah, django.utils.formats.localize is the main function to localize
> a value using the format localization engine from Python. The missing
> documentation is a bug, IMO.
Just a minor correction: localize does not use the localization engine
from Pytho
s.
No wonder the patch is quite big. I accidentally branched from the
conditional aggregation branch, so it has all the things in that patch
included. And that patch is much larger than the multicolumn_join
patch.
I pushed a new branch to github (https://github.com/akaariai/django/
tree/multic
On Jul 6, 1:39 am, akaariai wrote:
> Having said all this, for this project "extend the connection tuple"
> approach seems to be the only sane choice.
I implemented this in my github branch
https://github.com/akaariai/django/tree/composite_join
With this you can do:
a = Art
On Jun 27, 4:22 am, Michal Petrucha wrote:
> some visible progress on my project at long last. I spent most of the
> last week digging deep inside the ORM's entrails to make composite
> field lookups possible and finally it looks promising.
>
> While working on this I found out the extra_filters a
I have implemented proof of concept versions of conditional
aggregation, F-lookups in aggregates and annotating fields to a model
(qs.field_annotate(age_x2=F('age')*2), note: no aggregation here). See
ticket #11305 for more details.
I would also hope to implement a patch which would allow to annot
On Jul 2, 12:59 am, Ric wrote:
> Hi there,
>
> i have got a simple approach to make all django fields with a full
> i18n support
>
> the django.models.fields.Field class can be subclassed like this
>
> from django.db import models
> from django.utils.translation import get_language
>
> class i18nF
On Jun 28, 5:46 pm, Javier Guerra Giraldez wrote:
> i might be totally wrong (wouldn't be first time..) but i've found
> myself having to adapt to local dialects almost every time i see some
> SQL inside a function, especially on mysql and sqlite. maybe it's
> because of the bad quality of code
On Jun 28, 12:24 am, "Jim D." wrote:
> I spent some time last week and over the weekend nailing down a
> solution forhttps://code.djangoproject.com/ticket/3615. This is the
> ticket about allowing forward references when loading data on the
> MySQL InnoDB backend. My patch implements the proposed
On Jun 28, 5:18 pm, Javier Guerra Giraldez wrote:
> On Tue, Jun 28, 2011 at 8:41 AM, akaariai wrote:
> > This should translate to the following SQL:
> > SELECT sum(case when house.price > 41000 and house.price < 43000 then
> > 1 else 0 end) as expensive_house,
> >
On Jun 27, 4:54 pm, Russell Keith-Magee
wrote:
> > queryset.aggregate(
> > expensive_house=Count(house__price,
> > only=(Q(house__price__gt=41000), Q(house__price__lt=43000))),
> > ...
> > )
>
> Ok, so that's you're syntax proposal. Now show me the SQL that this
> translates into. In part
On Jun 17, 8:02 pm, Ian Kelly wrote:
> The thing is, this is a DB API snippet, not a Django snippet
> specifically. If Django were a DB API toolbox, then it might make
> sense to include it in some form or other. But it's not, so in the
> interest of keeping things relatively tidy I'm a -0 on t
On Jun 17, 2:54 pm, "Cal Leeming [Simplicity Media Ltd]"
wrote:
> Because I feel this is just something that should work (or be available) out
> of the box. There are plenty of other places where Django docs has included
> code snippets to give the user a heads up, and I think this is the perfect
On May 17, 5:32 pm, Michal Petrucha wrote:
> Proper subquery support is something that can be addressed once the
> rest of the implementation is stable.
To me the plan looks very reasonable (both disallowing subqueries and
converting to disjunction form), unless there is some part in the
internal
On May 12, 2:41 pm, Michal Petrucha wrote:
> Due to the nature of this field type, other lookup filters than
> ``exact`` and ``in`` would have unclear semantics and won't be
> supported. The original plan was to also exclude support for ``in``
> but as it turns out, ``in`` is used in several place
On May 13, 3:41 pm, Jeremy Dunck wrote:
> In general, the TestCase does a good job of cleaning up the
> environment (resetting the DB, etc.), but I've run across an edge case
> that might be worth putting upstream.
>
> I have a large codebase running multi-tenant -- lots of sites per WSGI
> proces
On Apr 15, 7:34 am, Ivan Sagalaev wrote:
> import logging
>
> import settings
> from django.core.management import setup_environ
> setup_environ(settings)
>
> from django.test.client import RequestFactory
>
> factory = RequestFactory()
> factory.get('/')
> l
ango (last commit is from
August 23, 2010).
[1] https://github.com/akaariai/django/tree/ticket10427
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
On Mar 30, 6:18 am, xtrqt wrote:
> def templ(context, divisibleby=divisibleby):
> my_list = context.get("my_list")
> _loop_len = len(my_list)
> result = []
> for forloop, i in enumerate(my_list):
> forloop = {
> "counter0": forloop,
On Mar 27, 5:48 am, "G.Boutsioukis" wrote:
> Hi, I'm thinking about submitting a proposal for template compilation
> and I'm posting this as a request for more info.
>
> In particular, I remember this project being discussed last year and I
> pretty much assumed that Alex Gaynor's proposal would h
On Mar 21, 1:20 pm, Michal Petrucha wrote:
> > My suggestion is to create an Index type that can be included in a
> > class just like a field can. The example we've been using would
> > then look like:
>
> > class Foo(Model):
> > x = models.FloatField()
> > y = models.FloatField()
> > a
On Mar 17, 3:11 am, Alexander Schepanovski wrote:
> Can you find that patch and post somewhere?
> If not still thanks for this idea.
Unfortunately, no. Gone with my old laptop.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
On Mar 16, 10:14 am, Thomas Guettler wrote:
> Hi Alexander,
>
> I have seen this in my app, too. It still runs fast enough. But
> I guess the django code could be optimized.
>
I had a patch for this problem somewhere, but can't find it now.
Basically it added inplace() method to queryset, and a
On Mar 5, 7:29 am, Karen Tracey wrote:
> It's probably best if you open a ticket in trac
> (http://code.djangoproject.com/newticket) for this. I can't think offhand how
> to solve both the problem that changeset fixed and the one you are
> encountering
>
If Django ORM would be able to perf
s used for viewing data, the link "Muokkaa"
in the upper left corner is a edit link.
http://users.tkk.fi/akaariai/Screenshot-7.png
The second picture is what you get when clicking the edit link. This
is rendered with {{ form.as_table }}.
http://users.tkk.fi/akaariai/Screenshot-8.png
It is
On Nov 5, 2:18 am, Alex Gaynor wrote:
> def setUp(self):
> self.old_SETTING = getattr(settings, "SETING", _missing)
>
> def tearDown(self):
> if self.old_SETTING is _missing:
> del settings.SETTING"
> else:
> settings.SETTING = self.old_SETTING
How about introducing a n
On 8 loka, 10:41, Hanne Moa wrote:
> You can't necessarily do this with a legacy database, as other systems
> also using that database expect the existing names.
alter sequence owned by does not change the sequnce name, just what
pg_get_serial_sequence will return for given table, column
combi
> Sorry, I should have been more clear.
>
> What I'm trying to do is solicit suggestions from django developers as
> to how I *can* move ticket #1946 forward. I can find a way to work
> around it in my own project, but it would be ideal to solve it on the
> Django side, for everybody.
>
> I mention
On Sep 28, 3:42 am, Luke Plant wrote:
> But can anyone else think of any gotchas with this change before I
> commit it? It produces a 30% improvement for the benchmark that relates
> to the ticket [3].
Not directly related to this change, but there are at least one part
in Django that will cache
On Sep 16, 10:43 am, Russell Keith-Magee
wrote:
> Do we have a continuous performance benchmark at present? No.
>
> Would it be worth having one? Certainly.
>
> There's a long standing ticket proposing just such a change:
>
> http://code.djangoproject.com/ticket/8949
>
> And there was a sprint ea
Is there any continuous speed testing done for Django? It would be
nice to see how performance of Django is evolving. For example while
working on ticket #14290, seeing how my changes to utils/translation/
__init__.py affect other parts of the framework would be useful. In
general, speed testing sh
When using related table based approach for the translations, django
could use pivoting to fetch all the translations with just one normal
join.
Some pseudo sql, skipping constrains and indexes...
create table a (
id integer pkey
);
create table b (
id integer pkey,
a_id integer references
36 matches
Mail list logo
