On Tue, Sep 25, 2012 at 11:24 AM, maxi wrote:
> El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey escribió:
>
>> First, this method is used during testing, generally not during normal
>> operation. It's implemented as a cached property so regardless of how
On Tue, Sep 25, 2012 at 11:24 PM, maxi wrote:
>
>
> El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey escribió:
>>
>> On Mon, Sep 24, 2012 at 10:15 PM, maxi wrote:
>>>
>>> Hi,
>>>
>>> DatabseFeatures class has a supports_transactions
On Tue, Sep 25, 2012 at 11:47 AM, Ian Kelly wrote:
> Thanks for putting together a pull request. Please note the patch
> will also need to update the documentation to state the new cx_Oracle
> version requirement (was 4.3.1, now 5.0.1).
Also, there should probably be
On Tue, Sep 25, 2012 at 1:31 AM, Shai Berger wrote:
> On Sunday 23 September 2012, Anssi Kääriäinen wrote:
>> Doing final polish for Ian's patch and providing benchmark results for it
>> will get this patch closer to commit.
>>
> I had hoped the Django test suite alone will
On 25 September 2012 17:45, Alex Ogier wrote:
> There's a big thing you cannot do without grouping models: you can't have
> an abstract base class relate to another abstract base class. Django's
> foreign key mechanism doesn't know how to relate to a to-be-instantiated
>
On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> It also seems the current abstract model mechanism can do everything a
> model library can minus the model prefixing and the model grouping; that
> though I would just tackle using a naming
On Tue, Sep 25, 2012 at 9:48 AM, Alex Gaynor wrote:
> My view is these things are 100% undocumented, 100% internal, anyone using
> them is 100% on their on. Simply put, if we can't make changes to these APIs
> without having to worry, what's the point in having a backwards
El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey escribió:
>
> On Mon, Sep 24, 2012 at 10:15 PM, maxi >wrote:
>
>> Hi,
>>
>> DatabseFeatures class has a supports_transactions property for test if
>> the db engine support transactions.
>>
On Tue, Sep 25, 2012 at 7:25 AM, Jacob Kaplan-Moss wrote:
> On Tue, Sep 25, 2012 at 3:23 AM, Anssi Kääriäinen
> wrote:
> > I'd like to postpone these to early next month so that I have more
> > time to help in reviews and pushing some new features in.
On Tue, Sep 25, 2012 at 3:23 AM, Anssi Kääriäinen
wrote:
> I'd like to postpone these to early next month so that I have more
> time to help in reviews and pushing some new features in. Other
> options are postponing review work, and postponing these patches to
> 1.6.
As
Hi Benoit,
as a matter of fact I want to add that to 1.5, and I started playing with a
small testapp to see what's needed:
https://github.com/apollo13/django-locale-switcher -- My conclusion is also
that stuffing the resolver_match on the request would be the best option.
We have another five
On Mon, Sep 24, 2012 at 10:15 PM, maxi wrote:
> Hi,
>
> DatabseFeatures class has a supports_transactions property for test if the
> db engine support transactions.
> supports_transactions implementation makes some metadata alters to check
> this behaivor.
>
> Now, is
Hi Benoît,
Thanks for the suggestion. It's tracked in
https://code.djangoproject.com/ticket/15695. This ticket hasn't seen much
activity, but I've heard this feature request several times.
I don't see much harm in adding the ResolverMatch as an attribute of the
request. ResolverMatch is already
Hi,
Here is a feature request : as a developer, I'd like to know the current
URL name, app name or namespace (or any information gathered during URL
resolution) within views, templates... i.e. attached to a request object.
Some use cases:
* display some content only if inside an application
Hi Jonathan, I am undecided on this one, when I first looked at it I thought it
was a great idea but now I feel it would be more problematic to read and
traverse and update such code due to the ModelFactory > MyModelFactory >
MyModels logic flow. It feels a lot like using class based views –
On Mon, Sep 24, 2012 at 9:55 AM, Jonathan Slenders
wrote:
> Hi everyone,
>
> This may be interesting to some of you. I created a small library for
> inheritance of a set of models.
> It's best to go quickly through the Readme on the site below.
>
> We felt a need for
> On 24 syys, 16:55, Jonathan Slenders
> wrote:
>> This may be interesting to some of you. I created a small library for
>> inheritance of *a set of* models.
>> It's best to go quickly through the Readme on the site below.
>>
>> We felt a need for this, but I'm
On 25 elo, 22:35, Anssi Kääriäinen wrote:
> I have done some more ORM refactoring work. I thought it would be a
> good idea to post a summary of what is going on.
>
> First, I haven't committed the utils.tree refactoring patch I was
> planning to commit
On Tuesday 25 September 2012 10:03:11 Anssi Kääriäinen wrote:
>
> Am I correct the benchmark is basically:
>
> cursor = connection.cursor()
> cursor.execute("some sql fetching many rows with NUMBER() columns")
> timer.start()
> for row in cursor.fetchall():
> pass
> print timer.used()
>
On 25 syys, 10:31, Shai Berger wrote:
> On Sunday 23 September 2012, Anssi Kääriäinen wrote:> Doing final polish for
> Ian's patch and providing benchmark results for it
> > will get this patch closer to commit.
>
> I had hoped the Django test suite alone will provide a
On 24 syys, 16:55, Jonathan Slenders
wrote:
> This may be interesting to some of you. I created a small library for
> inheritance of *a set of* models.
> It's best to go quickly through the Readme on the site below.
>
> We felt a need for this, but I'm wondering
On Sunday 23 September 2012, Anssi Kääriäinen wrote:
> Doing final polish for Ian's patch and providing benchmark results for it
> will get this patch closer to commit.
>
I had hoped the Django test suite alone will provide a convincing benchmark,
but apparently that is not the case -- on my
22 matches
Mail list logo