Re: Integrating polymorphic queries in the framework

Hosted version of the talk: http://www.roadside-developer.com/talks/2013-12-12_MelbDjango_MTI.Performance/#/ [Thanks, Brenton!] -- Curtis On 7 June 2014 11:52, Curtis Maloney wrote: > Can I draw your attention to Sebastian Vetter's investigation of the > relative

Re: Integrating polymorphic queries in the framework

Can I draw your attention to Sebastian Vetter's investigation of the relative scalability of different model polymorphism approaches : https://github.com/elbaschid/talks/tree/master/2013-12-12_MelbDjango_MTI.Performance Basically, the "select_related then resolve" approach [used in

Schema tests and test_foreign_key_index_long_names_regression

Hi, I'm trying to figured out how the test_foreign_key_index_long_names_regression method works. For my (using firebird backend) this test fails with: AssertionError: u'author_foreign_key_with_rea7ef8' not found in {u'ID': {'unique': False, 'primary_key': True}} I see that It's using

Re: Why not Single Table Inheritance?

On 6 juin 2014, at 09:42, Thomas Güttler wrote: > I think it is a "not invented here" syndrome: Ruby on Rails did it before. > That's > a reason to do it different. The reason is more simple. Rails was designed around MySQL, a database with a rather casual relationship to

Re: Why not Single Table Inheritance?

Let me expand on Russell's expletives: On Friday 06 June 2014 09:42:15 Thomas Güttler wrote: > > I guess a lot of developers don't want to hear the next lines: > > I think it is a "not invented here" syndrome: Ruby on Rails did it before. > That's a reason to do it different. > This does

Re: [GSOC] Weekly update

Hi All, Based on the work done last week, this week I have worked on the following: *1) Covered the current _meta implementation of unittests* The current Options is not covered by unit tests at all, I have created the model_options test module containing one or more unit tests for each

Re: [RFC] Python 3 and MySQL

While we're on the topic, I'd like to propose (also?) supporting the pure-python, MySQLdb-compatible pymysql, which INADA Naoki (methane) has also put a lot of work into. pymysql is pure-python, so it's really easy to get up-and running on Mac OS X and in other environments, because you don't

Re: LOCALE_PATHS should have a check to make sure it's a list/tuple

Sure, patches welcome. `django.conf.__init__` already has some "tuple_settings" logic which is looks like would probably work for this. On Friday, June 6, 2014 11:51:30 AM UTC-4, Tim Shaffer wrote: > > I'm playing around with 1.7b4 and I was trying to track down why my app > was not

LOCALE_PATHS should have a check to make sure it's a list/tuple

I'm playing around with 1.7b4 and I was trying to track down why my app was not auto-reloading when files were changed using the dev server. Turns out, it was an improperly configured LOCALE_PATHS setting. My LOCALE_PATHS was configured like this: LOCALE_PATHS = ( '/path/to/locale' ) At

Re: Integrating polymorphic queries in the framework

Don't know if it's a big patch at all. A polymorphic call could be like this: 1. Check if the class is polymorphic by itself or by inheritance: Traverse the inheritance D-Graph (we have to remember it's not a tree anymore) starting from the current class - It would stop on (and not count)

Re: Why not Single Table Inheritance?

On Fri, Jun 6, 2014 at 3:42 PM, Thomas Güttler wrote: > > > Am 26.05.2014 00:50, schrieb Craig de Stigter: > > If you ignore STI, I think it is quite straightforward to solve this with >>> a >>> >> parent model class which adds a type field, and manager methods to add the >>

Re: Why not Single Table Inheritance?

Am 26.05.2014 00:50, schrieb Craig de Stigter: If you ignore STI, I think it is quite straightforward to solve this with a parent model class which adds a type field, and manager methods to add the select_related calls and "interpret" the type field properly; so I don't see an immediate need