Re: Moving database backends out of the core

[Claude Paroz]

As for me, wearing my FOSS-only developper hat, I'd suggest we only include 
backends in core  for products having an OSI-approved license. And yes, the 
Oracle backend is already problematic at this regard. That would mean I'm 
-0 to -1 for including any other db backend (or any other component) based 
on a proprietary product.

Cheers,
Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[VernonCole]

Huh??  I am running sqlite with GIS on my laptop right now.  It wasn't THAT 
hard to install.  Yes, the documentation could use some cleanup, but it got 
me through the tutorial okay and gives me a platform to learn GIS on.
  I really support the idea of sqlite and postgres in the core and moving 
everything else outside.  
(Not that my support counts for much.)

On Wednesday, March 6, 2013 10:47:12 AM UTC-7, Florian Apolloner wrote:
>
> Hi,
>
> On Wednesday, March 6, 2013 3:32:45 PM UTC+1, Michael Manfre wrote: 
>>
>> The lack of data validation is definitely a nogo for production sites, 
>> but imo sqlite in production is also a nogo.
>>
>
> Right, but shipping Django with a non production db might send interesting 
> signals to endusers ;)
>
> The reference implementation should imo also have strong support for GIS, 
>>> which is somewhat okay on sqlite but quite hard to install. So if we were 
>>> to do that I'd either vote for postgres or supporting postgres and sqlite 
>>> inside of core (the later solely for fast tests).
>>>
>>
>> . I've never tried to install GIS for sqlite, but is the difficulty due 
>> to lack of documentation or just sheer number of steps?
>>
>
> Well it's not to bad, we did document it after all, but it usually 
> requires recompiling sqlite and pysqlite (most importantly you can't pull 
> it from your distros repos).
>
> Regards,
> Florian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

RE: Proposal: deprecate and remove django.contrib.comments

[Babatunde Akinyanmi]

+1

Sent from my Windows Phone
From: Jacob Kaplan-Moss
Sent: 3/7/2013 5:48 PM
To: django-developers
Subject: Proposal: deprecate and remove django.contrib.comments
Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.

My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and have much better features (spam prevents,
moderation, etc.). If you want something complex and specific, on the
other hand, you're better off writing something from scratch.

Practically, I'd do this by deprecating `django.contrib.comments` in
1.6. We'd immediately stop making any changes to it (except for
security or data loss issues). It'd stay deprecated in 1.7, and would
be removed in 1.8.

If someone volunteers to maintain it as an external project I'll move
the code to a new repo and direct people there in the docs. If nobody
volunteers, then it'll go to the great /dev/null in the sky.

Any objections?

Jacob

-- 
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee  wrote:

> I completely agree with Jacob's analysis of the status quo, and I agree
> largely with his position on having MSSQL in the core.
>
> I'd have no problem seeing MSSQL in the core - it's at least as high
> profile as Oracle, and although the demand for a MSSQL backend is
> restricted to a particular subset of the community, there is at least
> *some* demand for it to exist. Having MSSQL in core would allow us to hold
> our head high and say we support Microsoft platforms. Microsoft is even a
> member of the DSF at this point, so they're at least notionally interested
> in Django as a platform.
>

/slightly off topic
I didn't realize they were a DSF member. I have been wanting to set up
Jenkins to run the test suite on Windows with the ultimate goal of getting
its results added to ci.djangoproject.com. Knowing that Microsoft is a DSF
member will probably help gain access to a VM on Azure to make that a
reality. I've so far managed to get an introduction to a PM on one of the
Azure teams to help get a more direct answer to some Django, Windows, and
SQL problems that have been raised to my attention.

/back on topic

The maintenance burden is the problem. Historically, we've already had to
> *remove* a MSSQL backend because of bit rot (see [1]) - this isn't a
> pattern I want to repeat in the future. I don't want to add a backend to
> core unless I'm *certain* that it will see long term maintenance.
>
> [1] https://github.com/django/django/commit/c30a050e41
>

The demand for MSSQL would probably increase if it were included in core
because companies could be more confident about its ongoing support.

There are three options for using MSSQL with Django; django-pyodbc,
django-mssql, or write your own. The third option is not really a viable
option for most users.

django-pyodbc is cross platform, but not updated very often and has limited
stored procedure support. The official repo on Google code was last updated
in 2011, but there is a github fork with its last commit 8 months ago.

django-mssql is actively maintained and will be for at least the next few
years because it's used for my employer's production site that is critical
to business operations. The backend also supports stored procedures almost
to the same extent as a Windows business application. The only real
downside to the backend is that it only works on Windows, reducing its
usefulness to a much smaller, but growing, minority of Django users.

If Django wants to "hold [its] head high and support Microsoft platforms",
then I'm willing and capable of helping out with MSSQL and Windows support.
The only real caveat is that my employer needs me to maintain a certain
level of stored procedure functionality, so if MSSQL were included in the
core by using django-pyodbc instead of django-mssql, I would only be able
to commit personal time toward maintaining it, instead of also being able
to set aside business hours.

There is, however, a possible middle ground, following the example set by
> Flask: we introduce to Django a list of "officially recognised" extensions.
> These extensions are still maintained as external projects, but the core
> team promise to include these projects as part of the testing regimen for a
> release. If the MSSQL backend were recognised like this, we would run the
> full Django test suite against the MSSQL backend, and if that testing
> revealed a bug in the test suite which was identified as being due to a
> change in Django's codebase, that bug would be a release blocker (Bugs in
> the backend itself would still be the backend's responsibility, and not
> release blocking on Django)
>

This is sort of the idea I had in mind for backends while I was typing up
this proposal. You articulated it better than I did. A main problem I now
see with it is if the ownership of a bug cannot be mutually agreed upon
between Django and the extension, then this could cause doubt about what it
really means to be "officially recognized".

Regards,
Michael Manfre

Since DjangoCon, I now hear the email author's voice when reading some of
these emails.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Russell Keith-Magee]

On Fri, Mar 8, 2013 at 7:57 AM, Alex Ogier  wrote:

> Here's something I've been thinking about:
>
> As a rule, assuming that backends are not bug-riddled and do not have
> needlessly shoddy performance, nearly all of the value of an ORM is in the
> set of frontend features it exposes to application developers. Given a
> certain frontend API, then the only value in iterating the backend
> independently from the frontend is to fix uncaught bugs, or to improve
> performance, there's no value in adding features.
>
> Also as a rule, adding features to a frontend independently from the
> backend has little value. Without an implementation in whatever backend you
> are on, it only serves as a guide for future backend development, so you
> might as well push for backends to catch up in the same release cycle. (Or
> the feature doesn't require backend support, but then it doesn't hurt to
> reversion the backend anyways).
>
> So basically, there's not much value in independently versioning and
> maintaining frontends and backends to the ORM. This is in contrast to, say,
> localflavor, where an improvement in Mongolian localization can immediately
> help every Mongolian website in every Django version. So this primary
> motivation for independent maintenance is not a factor in the ORM. Hence I
> think the core team should include as many backends as it can handle in
> core (where "handle" means test that they function properly for each
> release). Oracle had been slipping, but from what I understand it's now in
> the CI server and back to passing most tests.
>
> So I see no reason to split off backends unless the maintenance burden is
> such that they are chronically broken in every Django release. And every
> reason to add MSSQL unless the maintenance burden is too high.
>

And that last clause is the catch.

I completely agree with Jacob's analysis of the status quo, and I agree
largely with his position on having MSSQL in the core.

I'd have no problem seeing MSSQL in the core - it's at least as high
profile as Oracle, and although the demand for a MSSQL backend is
restricted to a particular subset of the community, there is at least
*some* demand for it to exist. Having MSSQL in core would allow us to hold
our head high and say we support Microsoft platforms. Microsoft is even a
member of the DSF at this point, so they're at least notionally interested
in Django as a platform.

The maintenance burden is the problem. Historically, we've already had to
*remove* a MSSQL backend because of bit rot (see [1]) - this isn't a
pattern I want to repeat in the future. I don't want to add a backend to
core unless I'm *certain* that it will see long term maintenance.

[1] https://github.com/django/django/commit/c30a050e41

There is, however, a possible middle ground, following the example set by
Flask: we introduce to Django a list of "officially recognised" extensions.
These extensions are still maintained as external projects, but the core
team promise to include these projects as part of the testing regimen for a
release. If the MSSQL backend were recognised like this, we would run the
full Django test suite against the MSSQL backend, and if that testing
revealed a bug in the test suite which was identified as being due to a
change in Django's codebase, that bug would be a release blocker (Bugs in
the backend itself would still be the backend's responsibility, and not
release blocking on Django)

Looking outside database backends, this could also apply to high-profile
projects like haystack, django-registration, and so on. This would also
serve to highlight projects in our community that are 'defacto standards',
or good examples of reusability, without needing to expand the core team or
the size of contrib, and show that the core project is explicitly
interested in the broader ecosystem.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Jacob Kaplan-Moss]

On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee
 wrote:
> However, I'd argue against using /dev/null as a disposal mechanism. I don't
> think the code should ever completely disappear. If someone offers to take
> over, that's great; but just because nobody volunteers to maintain the
> project, doesn't mean nobody is using the code.

Yeah, that part was hyperbolic. I'll put it somewhere
(github.com/django/django-uncontrib-comments :) and invite anyone who
wants to maintain it to take it over.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Alex Gaynor]

It's not like /dev/null'ing it erases it from the annals of history. I
don't see what the point of creating an un-maintained repo is, if someone
decides they want to maintain it at some later point it's pretty trivial to
resurrect from VCS history.

Alex


On Thu, Mar 7, 2013 at 4:29 PM, Michael Manfre  wrote:

>
>
> On Thursday, March 7, 2013 1:05:53 PM UTC-5, Alex Ogier wrote:
>>
>> I think it can't just disappear. Even if you can't find a maintainer,
>> core should put at least a little effort to make sure that an API
>> compatible third-party application exists that is compatible at least
>> through version 1.8 when "import django.contrib.comments" stops working
>> (basically, do the work ourselves to make sure that it doesn't rely on
>> undocumented internals and can be cleanly split). Then, if it's not
>> maintained, it can fester and stop being compatible with new Django
>> versions or whatever. If it's really not important enough to anyone that it
>> can stay modern outside of core, then it will die, but we should make it a
>> trivial matter to fork and adopt for whoever needs it.
>>
>
> This approach sounds a lot better than just booting it from the repo.
>
> Regards,
> Michael Manfre
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Michael Manfre]

On Thursday, March 7, 2013 1:05:53 PM UTC-5, Alex Ogier wrote:
>
> I think it can't just disappear. Even if you can't find a maintainer, core 
> should put at least a little effort to make sure that an API compatible 
> third-party application exists that is compatible at least through version 
> 1.8 when "import django.contrib.comments" stops working (basically, do the 
> work ourselves to make sure that it doesn't rely on undocumented internals 
> and can be cleanly split). Then, if it's not maintained, it can fester and 
> stop being compatible with new Django versions or whatever. If it's really 
> not important enough to anyone that it can stay modern outside of core, 
> then it will die, but we should make it a trivial matter to fork and adopt 
> for whoever needs it.
>

This approach sounds a lot better than just booting it from the repo.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: move non-db tests out of TransactionTestCase

[zalew]

> +1 to you proposal. Please open a ticket. 
>

done https://code.djangoproject.com/ticket/20004 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Alex Ogier]

Here's something I've been thinking about:

As a rule, assuming that backends are not bug-riddled and do not have
needlessly shoddy performance, nearly all of the value of an ORM is in the
set of frontend features it exposes to application developers. Given a
certain frontend API, then the only value in iterating the backend
independently from the frontend is to fix uncaught bugs, or to improve
performance, there's no value in adding features.

Also as a rule, adding features to a frontend independently from the
backend has little value. Without an implementation in whatever backend you
are on, it only serves as a guide for future backend development, so you
might as well push for backends to catch up in the same release cycle. (Or
the feature doesn't require backend support, but then it doesn't hurt to
reversion the backend anyways).

So basically, there's not much value in independently versioning and
maintaining frontends and backends to the ORM. This is in contrast to, say,
localflavor, where an improvement in Mongolian localization can immediately
help every Mongolian website in every Django version. So this primary
motivation for independent maintenance is not a factor in the ORM. Hence I
think the core team should include as many backends as it can handle in
core (where "handle" means test that they function properly for each
release). Oracle had been slipping, but from what I understand it's now in
the CI server and back to passing most tests.

So I see no reason to split off backends unless the maintenance burden is
such that they are chronically broken in every Django release. And every
reason to add MSSQL unless the maintenance burden is too high.

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 4:03 PM, Erik Romijn  wrote:

> Hi all,
>
> It seems to me we are mixing a few different discussions here:
> 1. Should Django core have as few database backends as possible?
>  1a. If yes, which ones should stay in Django core?
> 2. What should we do, if anything, with the current situation where
>it seems difficult to guarantee the quality of the Oracle backend?
> 3. Should a MSSQL Django backend be included in Django core?
>
> Regarding question 1, I feel we should keep a fair set of backends,
> like the current one, included in Django core.
>
> Yes, we could move them to separate projects. All the same arguments
> apply here as why it's not necessarily good for a project to end up
> in contrib. However, in theory any component of Django could be moved
> out of core and be independently maintained. The whole ORM, the
> templating system, the CSRF protection, and so on. I haven't seen any
> reason why we should move the MySQL backend out, but not the templating
> system.
>
> Besides that, the close integration and development of all these parts
> is exactly the reason I like Django. When I download a version of Django,
> or upgrade, I know that all components in there will work well together.
> I can run my site on any of the supported databases, and they will all
> work together with the provided admin. I can build forms on the models
> I build with the ORM. The forms will nicely fit in with the templates.
>
> When I started using Django, I had looked at several alternatives which
> were more modular. However, they required me to make tons of choices,
> each involving numerous consequences. If I picked ORM A, I could have
> databases X, Y and Z, but no admin. For the admin I had to use ORM B,
> but that did not support database Z or many to many fields. And so on.
> When I tried Django, it was a relief to see I could download a single
> package, and everything would just work together.
>
> If we move database backends out of core, my big concern is that
> the same will happen there. This is fine for many components we use
> in many Django projects - but not for something as fundamental as the
> database backend. When the admin doesn't work on any of the officially
> supported backends, that should be a release blocker for Django itself,
> because I think it will be a blocker for the users.
>
> Regarding question 2, Oracle support, I think a great step forward has
> been made with the addition of Oracle to the Django continuous
> integration setup. That alone should help us improve the consistent
> quality of Oracle support.
>
> cheers,
> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an 

Re: Proposal: deprecate and remove django.contrib.comments

[Russell Keith-Magee]

On Fri, Mar 8, 2013 at 12:48 AM, Jacob Kaplan-Moss wrote:

> Hi folks --
>
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.
>
> Practically, I'd do this by deprecating `django.contrib.comments` in
> 1.6. We'd immediately stop making any changes to it (except for
> security or data loss issues). It'd stay deprecated in 1.7, and would
> be removed in 1.8.
>
> If someone volunteers to maintain it as an external project I'll move
> the code to a new repo and direct people there in the docs. If nobody
> volunteers, then it'll go to the great /dev/null in the sky.
>

+1 to trimming comments from contrib.

However, I'd argue against using /dev/null as a disposal mechanism. I don't
think the code should ever completely disappear. If someone offers to take
over, that's great; but just because nobody volunteers to maintain the
project, doesn't mean nobody is using the code.

Keeping the code in our repo with a big "DEPRECATED - THIS CODE IS NOT
MAINTAINED" warning in the README (or maybe even a new "django-attic"
repository) means the code can live on. If someone wants to use it, they
can. If someone needs to make a minor tweak, they can fork the repo and
make that change without needing to commit to maintaining the project
publicly.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: move non-db tests out of TransactionTestCase

[Ramiro Morales]

On Thu, Mar 7, 2013 at 5:32 PM, zalew  wrote:
> fall back to SimpleTestCase (which
> TransactionTestCase inherits from), but this class doesn't contain useful
> test helpers, which aren't in any way related to db handling:
>
> * assertRedirects
> * assert(Not)Contains
> * assertFormError
> * assertTemplate(Not)Used
> * _urlconf_setup(teardown).
>
> Is there a reason why these functions were bound to a transaction handling
> test class instead of SimpleTestCase?
>
> My proposal is to move them out either to SimpleTestCase, or a separate
> class other tests (including TransactionTestCase) can inherit from. I have
> experimentally written a SimpleTestCase based class for my needs, but I
> haven't yet tested it against the Django suite.
>
> What do you think? If you agree and/or have some ideas, I will submit an
> issue and work on a patch proposal.

We inserted [1]SimpleTestCase in the hierarchy relatively [2]recently
(Django 1.4) and moved some functionality to it from its subclasses.

But at that time I didn't even think about challenging the status quo and
move all the non-DB related like you've just done.

+1 to you proposal. Please open a ticket. This thread and the ticket should
give the topic the visibility it needs to raise alarms if there is any backward
compatibility involved.

Thanks!

1. 
https://docs.djangoproject.com/en/1.5/topics/testing/overview/#django.test.SimpleTestCase
2. https://docs.djangoproject.com/en/1.5/releases/1.4/#minor-features

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for review: database-level autocommit

[Aymeric Augustin]

On 7 mars 2013, at 17:37, Aymeric Augustin  
wrote:

> My work on transaction management is now ready for review:
> https://github.com/django/django/pull/873


It also fixes at least ten tickets. Here's a short explanation for those I 
found.

#2227: `atomic` supports nesting.
#6623: `commit_manually` is deprecated and `atomic` doesn't suffer from this 
defect.
#8320: the problem wasn't identified, but the legacy transaction management is 
deprecated.
#10744: the problem wasn't identified, but the legacy transaction management is 
deprecated.
#10813: since autocommit is enabled, it isn't necessary to rollback after 
errors any more.
#13742: savepoints are now implemented for SQLite.
#13870: transaction management in long running processes isn't a problem any 
more, and it's documented.
#14970: while it digresses on transaction management, this ticket essentially 
asks for autocommit on PostgreSQL.
#15694: `atomic` supports nesting.
#17887: autocommit makes it impossible for a connection to stay "idle of 
transaction".

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Erik Romijn]

Hi all,

It seems to me we are mixing a few different discussions here:
1. Should Django core have as few database backends as possible?
 1a. If yes, which ones should stay in Django core?
2. What should we do, if anything, with the current situation where 
   it seems difficult to guarantee the quality of the Oracle backend?
3. Should a MSSQL Django backend be included in Django core?

Regarding question 1, I feel we should keep a fair set of backends,
like the current one, included in Django core.

Yes, we could move them to separate projects. All the same arguments 
apply here as why it's not necessarily good for a project to end up
in contrib. However, in theory any component of Django could be moved 
out of core and be independently maintained. The whole ORM, the 
templating system, the CSRF protection, and so on. I haven't seen any 
reason why we should move the MySQL backend out, but not the templating 
system.

Besides that, the close integration and development of all these parts 
is exactly the reason I like Django. When I download a version of Django,
or upgrade, I know that all components in there will work well together. 
I can run my site on any of the supported databases, and they will all 
work together with the provided admin. I can build forms on the models 
I build with the ORM. The forms will nicely fit in with the templates.

When I started using Django, I had looked at several alternatives which 
were more modular. However, they required me to make tons of choices, 
each involving numerous consequences. If I picked ORM A, I could have 
databases X, Y and Z, but no admin. For the admin I had to use ORM B, 
but that did not support database Z or many to many fields. And so on.
When I tried Django, it was a relief to see I could download a single 
package, and everything would just work together.

If we move database backends out of core, my big concern is that 
the same will happen there. This is fine for many components we use 
in many Django projects - but not for something as fundamental as the 
database backend. When the admin doesn't work on any of the officially
supported backends, that should be a release blocker for Django itself,
because I think it will be a blocker for the users.

Regarding question 2, Oracle support, I think a great step forward has
been made with the addition of Oracle to the Django continuous 
integration setup. That alone should help us improve the consistent 
quality of Oracle support.

cheers,
Erik 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: move non-db tests out of TransactionTestCase

[Carl Meyer]

On 03/07/2013 01:32 PM, zalew wrote:
> I'm currently working on a project where I don't use db.* and I met a
> problem during testing. As django.test.testcases.TestCase [1] inherits
> from TransactionTestCase, it complains about "ImproperlyConfigured:
> settings.DATABASES". A solution is to fall back to SimpleTestCase (which
> TransactionTestCase inherits from), but this class doesn't contain
> useful test helpers, which aren't in any way related to db handling:
> 
> * assertRedirects
> * assert(Not)Contains
> * assertFormError
> * assertTemplate(Not)Used
> * _urlconf_setup(teardown).
> 
> Is there a reason why these functions were bound to a transaction
> handling test class instead of SimpleTestCase?
> 
> My proposal is to move them out either to SimpleTestCase, or a separate
> class other tests (including TransactionTestCase) can inherit from. I
> have experimentally written a SimpleTestCase based class for my needs,
> but I haven't yet tested it against the Django suite.

Sounds reasonable to me; those non-db-related helpers shouldn't need to
be on TransactionTestCase.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: move non-db tests out of TransactionTestCase

[zalew]

Hi

I'm currently working on a project where I don't use db.* and I met a 
problem during testing. As django.test.testcases.TestCase [1] inherits from 
TransactionTestCase, it complains about "ImproperlyConfigured: 
settings.DATABASES". A solution is to fall back to SimpleTestCase (which 
TransactionTestCase inherits from), but this class doesn't contain useful 
test helpers, which aren't in any way related to db handling: 

* assertRedirects 
* assert(Not)Contains 
* assertFormError 
* assertTemplate(Not)Used 
* _urlconf_setup(teardown). 

Is there a reason why these functions were bound to a transaction handling 
test class instead of SimpleTestCase?

My proposal is to move them out either to SimpleTestCase, or a separate 
class other tests (including TransactionTestCase) can inherit from. I have 
experimentally written a SimpleTestCase based class for my needs, but I 
haven't yet tested it against the Django suite.

What do you think? If you agree and/or have some ideas, I will submit an 
issue and work on a patch proposal.

[1] https://github.com/django/django/blob/master/django/test/testcases.py

Cheerz,
Jakub Zalewski

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: ModelForm API improvements

[Carl Meyer]

Hi Bruno,

On 03/07/2013 12:42 PM, Bruno Renié wrote:
> * Move formfield_for_* to ModelForm and document them as public APIs
> * Deprecate `formfield_callback`
> * Write an AdminModelForm class that implements all the admin form
> fields and widgets customization
> * Modify ModelAdmin to make use of that base class
> * (maybe?) deprecate ModelForm.Meta.widgets in favor of something
> similar to the admin's formfield_overrides, which is more generic.

I have run into #12915 before, and I'm enthusiastically in favor of the
first four items here. I agree that although formfield_callback is
technically not public API, it would be safer and not unreasonably
difficult to give it a deprecation path.

Regarding the fifth point, I think it would be great to have a simpler
way to override not only widgets, but also labels, help_texts, and error
messages on ModelForms (as discussed recently on
https://code.djangoproject.com/ticket/2 and in IRC). I don't
necessarily have a problem with unifying all of those into a single Meta
option, but I don't think it's really that much better than making them
separate options -- not enough so to justify a deprecation process for
Meta.widgets, IMO. Also, I think it's better for them to be indexed by
field name rather than type (formfield_overrides is indexed by type).

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: ModelForm API improvements

[Andrey Antukh]

Other possible option is for ideas:
http://django-crispy-forms.readthedocs.org/en/latest/index.html

;)


2013/3/7 Loic Bistuer 

> +1
>
> This logic would be better in `ModelForm`.
>
> --
> Loic
>
> On Mar 8, 2013, at 2:42 AM, Bruno Renié  wrote:
>
> My proposal is to move that field customization API from the
> ModelAdmin class back to ModelForm:
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: ModelForm API improvements

[Loic Bistuer]

+1

This logic would be better in `ModelForm`.

-- 
Loic

On Mar 8, 2013, at 2:42 AM, Bruno Renié  wrote:

> My proposal is to move that field customization API from the
> ModelAdmin class back to ModelForm:

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: ModelForm API improvements

[Bruno Renié]

Hello,

There was some discussion on the current limitations of the ModelForm
API in the past couple of days on IRC, I'd like to make a proposal to
address some of them.

I wrote django-floppyforms, a library that lets you render forms using
templates instead of python code. It behaves exactly like the Django
forms library, the only difference is the import path. Import
`floppyforms as forms` and when you render a form, the HTML code comes
from templates.

There is still a limitation with ModelForms: since there is no way to
globally override the model field -> form field/widget mapping since
ModelForms fields come from the model definition. I documented this
here:

http://django-floppyforms.readthedocs.org/en/latest/differences.html#modelforms

It is possible to override widgets using the Meta.widgets dict but not
in a way that would switch all the ModelForm's fields to
template-based widgets automatically. The idea is to have custom
ModelForm subclasses with specific strategy on the model field -> form
field mapping.

This is currently possible using something called `formfield_callback`
as a ModelForm class attribute: it is simply a callback that takes a
db field and returns a form field. But this callback is a) private and
b) limited: it gets lost in the inheritance chain as described in
ticket #12915:

https://code.djangoproject.com/ticket/12915

A discussion thread was started a couple of days ago for a design
decision about formfield_callback: should we consider its behaviour as
buggy or leave it as it is? In fact formfield_callback is only used by
the admin, which has custom widgets for pretty much every db field.
This customization is done using the following methods and attributes
(all in django/contrib/admin/options.py):

FORMFIELD_FOR_DBFIELD_DEFAULTS
ModelAdmin.formfield_overrides
ModelAdmin.formfield_for_dbfield(db_field, **kwargs)
ModelAdmin.formfield_for_choicefield(db_field, **kwargs)
ModelAdmin.formfield_for_foreignkey(db_field, **kwargs)
ModelAdmin.formfield_for_manytomany(db_field, **kwargs)

In most cases those methods end up calling formfield() on the DB field
object, with some arguments for customizing the field class (wrongly
called `form_class`) and its constructor arguments (widget, label,
help_text, required, etc).

The arguments to db_field.formfield() are passed via the
formfield_callback function I mentioned earlier.

My proposal is to move that field customization API from the
ModelAdmin class back to ModelForm:

* Move formfield_for_* to ModelForm and document them as public APIs
* Deprecate `formfield_callback`
* Write an AdminModelForm class that implements all the admin form
fields and widgets customization
* Modify ModelAdmin to make use of that base class
* (maybe?) deprecate ModelForm.Meta.widgets in favor of something
similar to the admin's formfield_overrides, which is more generic.

I see the following advantages to this:

* This would allow people to have "site-wide" fields/widgets
overrides, which is a feature that the admin is already proving
useful. Write a nice date picker once, register it for all your
DateFields globally.

* Maintainers of form libraries can ship a base ModelForm class that
implements custom fields/widgets while keeping API compatibility with
Django.

Backwards-compatibility shouldn't be an issue as this touches only a
couple of ModelAdmin methods. Regarding formfield_callback, despite it
being a private API I'm not sure it can be removed safely. There are
references to it on StackOverflow and on the Django bug tracker.

I'm happy to work on a patch if core devs agree to accept this. Thoughts?

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Javier Guerra Giraldez]

On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown  wrote:
> I've only tried using django.contrib.comments once, and it ended up not
> being what I needed anyway, so I had to write my own comments module (Disqus
> was out of the question)


i had exactly the same experience.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Switch to database-level autocommit

[Shai Berger]

On Wednesday 06 March 2013, Aymeric Augustin wrote:
> 
> So part 3 of the plan is to replace TransactionMiddleware by something
> based on transaction.atomic that actually works. For lack of a better
> idea, I'm considering deprecating the middleware and replacing it with a
> setting. This doesn't qualify as loose coupling; better ideas welcome!

Another half-baked idea: I think atomic_urlpatterns (which wrap the view 
callables in @atomic) could do a lot of the trick. They would leave middleware 
database accesses out of the transaction, which could turn out to be a 
"gotcha", but could be acceptable in many cases.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Alex Ogier]

It's worth mentioning that Django appears in the Python Tools for Visual
Studio (it's one of the default project templates)[1]. There's recent
introductory material on deploying Django applications to Windows Azure[2]
and Windows Server 2008[3], though it seems the older material at least
explicitly recommends MySQL and not SQL Server. I don't know if this is the
kind of thing that leads to demand among Windows folks for Windows support
for Django, and if any significant fraction of them want to use MSSQL with
Django, but Django is certainly becoming mainstream for them.

[1]: http://pytools.codeplex.com/
[2]:
http://www.windowsazure.com/en-us/develop/python/tutorials/django-with-visual-studio/
[3]:
http://www.windowsazure.com/en-us/develop/python/tutorials/web-app-with-django-and-mysql/

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 12:46 PM, Jacob Kaplan-Moss wrote:

> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn  wrote:
> > I don't know why Oracle is included and MSSQL is not [...]
>
> It's essentially because a group of people made a concerted effort to
> get the Oracle backend up to snuff (around the 1.0 timeline, I think?)
> and then committed to maintaining it. Lately the original people who'd
> made that commitment have dropped off a bit, but there's always been
> enough attention to keep it up to date.
>
> If someone -- preferably a group -- stepped up and committed to
> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it
> and giving those people commit access to keep it up to date.
>
> [This is me speaking personally, not as a BDFL. It'd have to be a
> discussion, not just my fiat.]
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Alex Ogier]

I think it can't just disappear. Even if you can't find a maintainer, core
should put at least a little effort to make sure that an API compatible
third-party application exists that is compatible at least through version
1.8 when "import django.contrib.comments" stops working (basically, do the
work ourselves to make sure that it doesn't rely on undocumented internals
and can be cleanly split). Then, if it's not maintained, it can fester and
stop being compatible with new Django versions or whatever. If it's really
not important enough to anyone that it can stay modern outside of core,
then it will die, but we should make it a trivial matter to fork and adopt
for whoever needs it.

Anyways, +1 from me.

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown wrote:

> +1 from me too - I've only tried using django.contrib.comments once, and
> it ended up not being what I needed anyway, so I had to write my own
> comments module (Disqus was out of the question)
>
>
> On Thu, Mar 7, 2013 at 5:11 PM, Carlos Aguilar wrote:
>
>> I think i can maintain comments if you want the time you need.
>>
>> I only use few zinnia blogs, then, is not really important to me, but I
>> suppose it is important for many others developers.
>>
>> Best Regards
>>
>>
>> On Thu, Mar 7, 2013 at 11:00 AM, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> On 7 mars 2013, at 17:48, Jacob Kaplan-Moss  wrote:
>>>
>>> > This one's simple: I'd like to deprecate `django.contrib.comments`,
>>> > scheduling it to be removed in a couple of releases.
>>>
>>> +1
>>>
>>> > My rationale is this: if you don't really care much about how comments
>>> > work but just want something easy, then Disqus (and its competitors)
>>> > are easier to use and have much better features (spam prevents,
>>> > moderation, etc.). If you want something complex and specific, on the
>>> > other hand, you're better off writing something from scratch.
>>>
>>> The mere existence of django.contrib.comments implies that it's the
>>> sanctioned way to add comments to a Django application, but in 2013
>>> it's most likely not going to be the right answer. Leaving it in contrib
>>> is a disservice to many developers using Django.
>>>
>>> Even www.djangoproject.com stopped using d.c.comments in 2009.
>>>
>>> > If someone volunteers to maintain it as an external project I'll move
>>> > the code to a new repo and direct people there in the docs. If nobody
>>> > volunteers, then it'll go to the great /dev/null in the sky.
>>>
>>> Even if no one volunteers to maintain it, I'd still consider putting it
>>> on
>>> life support somewhere under github.com/django. The goal is to
>>> provide an easier upgrade path for maintainers of websites currently
>>> using it.
>>>
>>> Otherwise we'll have people stuck at the last version of Django that
>>> still contains d.c.comments.
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>> --
>> Carlos Aguilar
>> Consultor Hardware y Software
>> DWD
>> http://www.dwdandsolutions.com
>> http://www.houseofsysadmin.com
>> Cel: +50378735118
>> USA: (301) 337-8541
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at 

Re: Moving database backends out of the core

[Jacob Kaplan-Moss]

On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn  wrote:
> I don't know why Oracle is included and MSSQL is not [...]

It's essentially because a group of people made a concerted effort to
get the Oracle backend up to snuff (around the 1.0 timeline, I think?)
and then committed to maintaining it. Lately the original people who'd
made that commitment have dropped off a bit, but there's always been
enough attention to keep it up to date.

If someone -- preferably a group -- stepped up and committed to
keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it
and giving those people commit access to keep it up to date.

[This is me speaking personally, not as a BDFL. It'd have to be a
discussion, not just my fiat.]

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Luke Granger-Brown]

+1 from me too - I've only tried using django.contrib.comments once, and it
ended up not being what I needed anyway, so I had to write my own comments
module (Disqus was out of the question)


On Thu, Mar 7, 2013 at 5:11 PM, Carlos Aguilar wrote:

> I think i can maintain comments if you want the time you need.
>
> I only use few zinnia blogs, then, is not really important to me, but I
> suppose it is important for many others developers.
>
> Best Regards
>
>
> On Thu, Mar 7, 2013 at 11:00 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> On 7 mars 2013, at 17:48, Jacob Kaplan-Moss  wrote:
>>
>> > This one's simple: I'd like to deprecate `django.contrib.comments`,
>> > scheduling it to be removed in a couple of releases.
>>
>> +1
>>
>> > My rationale is this: if you don't really care much about how comments
>> > work but just want something easy, then Disqus (and its competitors)
>> > are easier to use and have much better features (spam prevents,
>> > moderation, etc.). If you want something complex and specific, on the
>> > other hand, you're better off writing something from scratch.
>>
>> The mere existence of django.contrib.comments implies that it's the
>> sanctioned way to add comments to a Django application, but in 2013
>> it's most likely not going to be the right answer. Leaving it in contrib
>> is a disservice to many developers using Django.
>>
>> Even www.djangoproject.com stopped using d.c.comments in 2009.
>>
>> > If someone volunteers to maintain it as an external project I'll move
>> > the code to a new repo and direct people there in the docs. If nobody
>> > volunteers, then it'll go to the great /dev/null in the sky.
>>
>> Even if no one volunteers to maintain it, I'd still consider putting it on
>> life support somewhere under github.com/django. The goal is to
>> provide an easier upgrade path for maintainers of websites currently
>> using it.
>>
>> Otherwise we'll have people stuck at the last version of Django that
>> still contains d.c.comments.
>>
>> --
>> Aymeric.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
> --
> Carlos Aguilar
> Consultor Hardware y Software
> DWD
> http://www.dwdandsolutions.com
> http://www.houseofsysadmin.com
> Cel: +50378735118
> USA: (301) 337-8541
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Alex Gaynor]

Jumpin' on the +1 train.

Choo, choo!
Alex


On Thu, Mar 7, 2013 at 9:04 AM, Donald Stufft  wrote:

> On Mar 7, 2013, at 11:48 AM, Jacob Kaplan-Moss  wrote:
>
> > Hi folks --
> >
> > This one's simple: I'd like to deprecate `django.contrib.comments`,
> > scheduling it to be removed in a couple of releases.
> >
> > My rationale is this: if you don't really care much about how comments
> > work but just want something easy, then Disqus (and its competitors)
> > are easier to use and have much better features (spam prevents,
> > moderation, etc.). If you want something complex and specific, on the
> > other hand, you're better off writing something from scratch.
> >
> > Practically, I'd do this by deprecating `django.contrib.comments` in
> > 1.6. We'd immediately stop making any changes to it (except for
> > security or data loss issues). It'd stay deprecated in 1.7, and would
> > be removed in 1.8.
> >
> > If someone volunteers to maintain it as an external project I'll move
> > the code to a new repo and direct people there in the docs. If nobody
> > volunteers, then it'll go to the great /dev/null in the sky.
> >
> > Any objections?
> >
> > Jacob
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> +1
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Carlos Aguilar]

I think i can maintain comments if you want the time you need.

I only use few zinnia blogs, then, is not really important to me, but I
suppose it is important for many others developers.

Best Regards


On Thu, Mar 7, 2013 at 11:00 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 7 mars 2013, at 17:48, Jacob Kaplan-Moss  wrote:
>
> > This one's simple: I'd like to deprecate `django.contrib.comments`,
> > scheduling it to be removed in a couple of releases.
>
> +1
>
> > My rationale is this: if you don't really care much about how comments
> > work but just want something easy, then Disqus (and its competitors)
> > are easier to use and have much better features (spam prevents,
> > moderation, etc.). If you want something complex and specific, on the
> > other hand, you're better off writing something from scratch.
>
> The mere existence of django.contrib.comments implies that it's the
> sanctioned way to add comments to a Django application, but in 2013
> it's most likely not going to be the right answer. Leaving it in contrib
> is a disservice to many developers using Django.
>
> Even www.djangoproject.com stopped using d.c.comments in 2009.
>
> > If someone volunteers to maintain it as an external project I'll move
> > the code to a new repo and direct people there in the docs. If nobody
> > volunteers, then it'll go to the great /dev/null in the sky.
>
> Even if no one volunteers to maintain it, I'd still consider putting it on
> life support somewhere under github.com/django. The goal is to
> provide an easier upgrade path for maintainers of websites currently
> using it.
>
> Otherwise we'll have people stuck at the last version of Django that
> still contains d.c.comments.
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Carlos Aguilar
Consultor Hardware y Software
DWD
http://www.dwdandsolutions.com
http://www.houseofsysadmin.com
Cel: +50378735118
USA: (301) 337-8541

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Donald Stufft]

On Mar 7, 2013, at 11:48 AM, Jacob Kaplan-Moss  wrote:

> Hi folks --
> 
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
> 
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.
> 
> Practically, I'd do this by deprecating `django.contrib.comments` in
> 1.6. We'd immediately stop making any changes to it (except for
> security or data loss issues). It'd stay deprecated in 1.7, and would
> be removed in 1.8.
> 
> If someone volunteers to maintain it as an external project I'll move
> the code to a new repo and direct people there in the docs. If nobody
> volunteers, then it'll go to the great /dev/null in the sky.
> 
> Any objections?
> 
> Jacob
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

+1 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Marc Tamlyn]

Seems to me that if database backends were separate from Django then the 
postgres backend would get a long way ahead of the others as much as the 
other backends would get behind - it's bound to attract the most work and 
be adding custom fields like hstore, arrays, json... I think this would be 
great for most of my use cases, but then again I also have to deploy a 
small proportion of sites on MySQL, so it's bound to bite me.

That said, I don't know why Oracle is included and MSSQL is not - pretty 
much none of the core devs currently use either (or would recommend it 
given the choice). Cross compatibility of Django core is really important, 
and should ideally be as far reaching as we can achieve. I'd rather see 
MSSQL pulled in, and hopefully testing of it via Travis at some point than 
things split out, as I think it's better for Django.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Travis support (again)

[Jacob Kaplan-Moss]

On Mon, Feb 25, 2013 at 4:48 PM, Florian Apolloner
 wrote:
> So all in all I think we could enable travis,

I agree, +1 from me.

> but I have two questions:
>  * How much bash magic do we want in the .travis.yml file? One option would
> be to use a separate repo like I did in my initial work:
> https://github.com/apollo13/django/blob/travisci/.travis.yml (Personally I
> prefer my approach a bit more since it would keep the git history clean of
> changes which are only needed to configure travis properly if the baseimage
> changes etc...)

Yes, I like this. I'm constantly committing "fix travis" commits on my
other repos that use Travis, and that's annoying an crappy for a
project with a public timeline. So let's do something like a
"github.com/django/travis-support" repo and keep the .travis file
simple and clean.

>  * Any objections to ship a file like the test_ci.py file in the PR (+ the
> accompaning docs, especially with regard to dj-database-url)?

I'd rather see this in the travis-support (or whatever) repo.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Aymeric Augustin]

On 7 mars 2013, at 17:48, Jacob Kaplan-Moss  wrote:

> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.

+1

> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.

The mere existence of django.contrib.comments implies that it's the
sanctioned way to add comments to a Django application, but in 2013
it's most likely not going to be the right answer. Leaving it in contrib
is a disservice to many developers using Django.

Even www.djangoproject.com stopped using d.c.comments in 2009.

> If someone volunteers to maintain it as an external project I'll move
> the code to a new repo and direct people there in the docs. If nobody
> volunteers, then it'll go to the great /dev/null in the sky.

Even if no one volunteers to maintain it, I'd still consider putting it on
life support somewhere under github.com/django. The goal is to
provide an easier upgrade path for maintainers of websites currently
using it.

Otherwise we'll have people stuck at the last version of Django that
still contains d.c.comments.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Mikhail Korobov]

A good idea, +1.

четверг, 7 марта 2013 г., 22:48:11 UTC+6 пользователь Jacob Kaplan-Moss 
написал:
>
> Hi folks -- 
>
> This one's simple: I'd like to deprecate `django.contrib.comments`, 
> scheduling it to be removed in a couple of releases. 
>
> My rationale is this: if you don't really care much about how comments 
> work but just want something easy, then Disqus (and its competitors) 
> are easier to use and have much better features (spam prevents, 
> moderation, etc.). If you want something complex and specific, on the 
> other hand, you're better off writing something from scratch. 
>
> Practically, I'd do this by deprecating `django.contrib.comments` in 
> 1.6. We'd immediately stop making any changes to it (except for 
> security or data loss issues). It'd stay deprecated in 1.7, and would 
> be removed in 1.8. 
>
> If someone volunteers to maintain it as an external project I'll move 
> the code to a new repo and direct people there in the docs. If nobody 
> volunteers, then it'll go to the great /dev/null in the sky. 
>
> Any objections? 
>
> Jacob 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Carl Meyer]

On 03/07/2013 09:48 AM, Jacob Kaplan-Moss wrote:
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
> 
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.

+1

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: deprecate and remove django.contrib.comments

[Jacob Kaplan-Moss]

Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.

My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and have much better features (spam prevents,
moderation, etc.). If you want something complex and specific, on the
other hand, you're better off writing something from scratch.

Practically, I'd do this by deprecating `django.contrib.comments` in
1.6. We'd immediately stop making any changes to it (except for
security or data loss issues). It'd stay deprecated in 1.7, and would
be removed in 1.8.

If someone volunteers to maintain it as an external project I'll move
the code to a new repo and direct people there in the docs. If nobody
volunteers, then it'll go to the great /dev/null in the sky.

Any objections?

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Request for review: database-level autocommit

[Aymeric Augustin]

My work on transaction management is now ready for review:
https://github.com/django/django/pull/873


To sum up, the main improvements over the current implementation are:

1) A better API for transactions
- Simple: just one function covers most of the use cases
- Correct: it actually guarantees atomicity
- Pythonic: it's fully nestable

2) No implicit transactions
- More predictable
- Better performance
- Eliminates dangling transactions ("idle in transaction")
- even in long running processes

3) More maintainable
- More documentation
- Less code, at least from 1.8 onwards
- Closer to the database — avoids problems with the adapters

The main concern is backwards-compatibility. It was discussed at
length in the previous thread. I acknowledge the consequences,
and I documented them.


Here's what you should know before starting a review.

I've rewritten history heavily to make the branch as reviewable as
possible.

I refactored away the old transaction management code in small steps
to avoid introducing unintentional backwards-incompatibilities. I suggest
reviewing the code changeset by changeset.

Some commits make very large edits to the docs and are impossible to
review. I recommend reading only the final version of the docs.


I will avoid force-pushing from now on. Please checkout my branch and
test it!

Barring unexpected problems and last minute vetoes, I plan to merge
this branch when another core dev reviews it thoroughly and accepts it,
or before the PyCon sprints (in 10 days), whichever comes first. Let me
know if you'd like more time to review it.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Switch to database-level autocommit

[Aymeric Augustin]

On 6 mars 2013, at 23:21, Aymeric Augustin  
wrote:

>  using a WSGI middleware. It's two lines of code:
> 
> from django.core.wsgi import get_wsgi_application
> application = get_wsgi_application()
> 
> for db in ('default', 'other'):
> application = atomic(using=db)(application)
> 
> I'm leaning towards simply documenting that.


Sadly, this doesn't work. The atomic block needs to be inside Django's
exception hander. Otherwise, its __exit__ will never see an exception.

Sorry for the noise.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: About GSoC 2013

[Mayur Patil]

   Thank you Sir for reply.
*
--
Cheers,
Mayur*

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.