Re: [ANNOUNCE] Django 1.8 alpha 1 released

[Fabio Caritas Barrionuevo da Luz]

Em sexta-feira, 16 de janeiro de 2015 20:10:37 UTC-3, Tim Graham escreveu:
>
> We've made the first release on the way to Django's next long-term support 
> release, Django 1.8! With only two and a half months until the scheduled 
> final release, we'll need prompt testing from the community to ensure a 
> timely and stable release. Check out the blog post:
>
>
> https://www.djangoproject.com/weblog/2015/jan/16/django-18-alpha-1-released/
>


Wow, many new things. Very good.

I have not seen in the release-notes that the inspectdb now supports 
inspect "database views" to the backends where it is supported.

This change was made in this commit:

https://github.com/django/django/commit/b8cdc7dcc3fc6897fb2a75f90023f5c67aad327f
 

See the "get_table_list" function in introspection.py file, in each 
database backend

I look forward a day, that Django has support for inspecting "multiple 
database schemas" and work properly with an official api to do this.

https://code.djangoproject.com/ticket/22673
https://code.djangoproject.com/ticket/6148

I was trying to figure out ways to solve this old problem of django.
Also i know that adding support for multiple database schemas is not 
something trivial for Django, because if it was, I'm sure that would be 
already been implemented.

https://gist.github.com/luzfcb/e5f67e9c940e4833b798
http://dba.stackexchange.com/questions/87463/in-oracle-how-to-get-a-list-with-the-names-of-schemas-that-a-user-has-read-perm



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e1efdd2-b8d4-4f7d-a498-188f06ff8999%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.8 alpha 1 released

[Tim Graham]

We've made the first release on the way to Django's next long-term support 
release, Django 1.8! With only two and a half months until the scheduled 
final release, we'll need prompt testing from the community to ensure a 
timely and stable release. Check out the blog post:

https://www.djangoproject.com/weblog/2015/jan/16/django-18-alpha-1-released/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/28462ef9-4769-4cfb-bb8c-65ac035506ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - January 16, 2015

[Tim Graham]

Here’s my final report for the 3 month fellowship pilot. I hope the DSF’s 
fundraising efforts will be successful and I’ll have an opportunity to "be 
back" soon. :-)


On Monday, I reviewed the last couple of tickets before the 1.8 feature 
freeze. On Tuesday, we had the security release. I’ve been working in the 
background on putting that release together for the last month or so. The 
rest of the week was focused on polishing the master branch and fixing 
regressions to get it in a good state for today's release of 1.8 alpha 1. 
If all goes well, we’ll get lots of testers and will be able to release a 
more polished "beta" in about a month.

Report for week ending January 16, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24112 - Inconsistency in 
TestCase.assertInHTML (accepted)

https://code.djangoproject.com/ticket/24086 - No pre_migrate signal is 
emitted if rolling back the migration history (worksforme)

https://code.djangoproject.com/ticket/24148 - test_combined_expression test 
failure on Windows/Python 2 (created)

https://code.djangoproject.com/ticket/24155 - Make migration generation 
more deterministic (accepted)

https://code.djangoproject.com/ticket/24142 - extra() field overwritten 
when using union on two querysets (accepted)

Authored



https://github.com/django/django/pull/3899 - Fixed #22603 -- Organized 
django.db.backends classes

https://github.com/django/django/pull/3923 - Fixed #24135 -- Made 
RenameModel rename many-to-many tables.

Reviewed/committed

--

https://github.com/django/django/pull/3889 - Fixed #23878 -- Move Query and 
Prefetch documentation

https://github.com/django/django/pull/3897 - Fixed #24124 -- Changed 
context_processors in the default settings.py

https://github.com/django/django/pull/3825 - Fixed #24031 -- Added CASE 
expressions

https://github.com/django/django/pull/3876 - Fixed #24089 -- Added check 
for when ModelAdmin.fieldsets[1]['fields'] isn't a tuple.

https://github.com/django/django/pull/3847 - Fixed #23712 -- Fixed KeyError 
with BaseForm._html_output()

https://github.com/django/django/pull/3926 - Fixed #24148 -- Documented the 
bug with case expressions in SQLite < 3..0.

https://github.com/django/django/pull/3879 - Fixed #9893 -- Allowed using a 
field's max_length in the Storage.
https://github.com/django/django/pull/3918 - Fixed #24146 -- Fixed a 
missing fields regression in admin checks.

Reviews of core dev work



https://github.com/django/django/pull/3883 - Multiple template engines - 
continued

https://github.com/django/django/pull/3868 - Fixed #24060 -- Added OrderBy 
Expressions

https://github.com/django/django/pull/3878 - Fixed #24092 -- Widened base 
field support for ArrayField.

https://github.com/django/django/pull/3890 - Fixed #24123 -- Used all 
available migrations to generate the initial migration state

https://github.com/django/django/pull/3891 - Fixed #24129 -- Added 
indicator that migrations are rendering the initial state

https://github.com/django/django/pull/3913 - Fixed #24147 -- Prevented 
managers leaking model during migrations

https://github.com/django/django/pull/3894 - Fixed #24075 -- Prevented 
running post_migrate signals when unapplying initial migrations of 
contenttypes and auth

https://github.com/django/django/pull/3920 - Fixed #24152 -- Deprecated 
GeoQuerySet aggregate methods

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b1676d67-aaa1-4c03-adfa-dee12f55d3ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Collin Anderson]

Hi All,

Should change tuples to lists in more places in the docs?
https://github.com/django/django/pull/3929

Collin

On Thursday, December 18, 2014 at 7:56:47 AM UTC-5, Carl Meyer wrote:
>
> On 12/17/2014 11:49 PM, Russell Keith-Magee wrote: 
> > On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer  > wrote: 
> >> This is clever, but on second thought I'm trying to figure out in what 
> >> scenario a backwards-compatibility would actually occur here. In the 
> >> context of a user's settings modules, global_settings plays no role at 
> >> all: you can't add to a global setting default in your settings.py 
> >> (unless you've imported global_settings yourself, which is certainly 
> >> making use of undocumented internals). 
> >> 
> >> So it seems to me that the only scenario in which this would actually 
> >> cause a back-compat problem would be if someone is using a tuple 
> >> setting, which they are not setting themselves (and thus are using the 
> >> global default), and they are adding to it in their runtime code (not 
> in 
> >> their settings file). For instance: 
> >> 
> >> my_ctx_procs = settings.TEMPLATE_CONTEXT_PROCESSORS + ('another',) 
> >> 
> >> The common case of appending to a setting in your settings.py (due to 
> >> use of some kind of split-settings) should not be impacted at all 
> >> 
> > 
> > That's a fair point. The benefit for an __add__ definition is likely to 
> be 
> > a lot smaller than I originally thought. 
> > 
> > The only place I can think that it might pop up is in older (pre 
> > @override_settings) test harnesses; that said, a failure during test 
> isn't 
> > a major inconvenience 
> > 
> > So - I retract my suggestion - I think I can live with just documenting 
> > this as a backwards compatibility. 
>
> Works for me! 
>
> Carl 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/38ba3ba6-86e3-40c5-b251-6a6ed2d3f3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.