Fellow Report - October 31, 2015
On the infrastructure front, I completed pull request integration for the
Windows build, so that’s a new status check that runs on all pull requests
that also run the tests on Linux.
Sorry about the djangoproject.com outage on Monday -- that was due to some
unexpected problems during Rackspace maintenance and out of our hands.
Thanks to Florian and Jannis for investigating it while I was asleep.
I’m arriving in London on Monday morning for a couple days before traveling
to Amsterdam for Django Under the Hood. If you are in London and would like
to meet up, shoot me an email. I always enjoy meeting Django users and
contributors. I look forward to meeting old and new friends at the
conference too!
Triaged
---
https://code.djangoproject.com/ticket/25606 - Add support for "__" lookup
in RelatedOnlyFieldListFilter (accepted)
https://code.djangoproject.com/ticket/18201 - smallint and tinyint fields +
auto increment (duplicate)
https://code.djangoproject.com/ticket/25613 - Transactional Cache TestCase
(duplicate)
https://code.djangoproject.com/ticket/25614 - Changing
ForeignKey(on_delete=...) unnecessarily drops and recreates constraints
(duplicate)
https://code.djangoproject.com/ticket/16391 - New URL tag for reversing
urls with placeholder args/kwargs (wontfix)
https://code.djangoproject.com/ticket/17756 - GeoDjango missing
pyspatialite support (wontfix)
https://code.djangoproject.com/ticket/25615 - multidb Relation fields do
not support nested lookups (invalid)
https://code.djangoproject.com/ticket/25618 - Django migration system
breaks with unhelpful error message if south migrations accidentally
retained (fixed)
https://code.djangoproject.com/ticket/25623 - Django always returns a white
page along with 400 on latin encoded URLs. (accepted)
https://code.djangoproject.com/ticket/25624 - Autoreload fails if
jinja2.ModuleLoader used (accepted)
https://code.djangoproject.com/ticket/25626 - Storing big strings with
special chars fails when using PostgreSQL with SQL_ASCII encoding (invalid)
https://code.djangoproject.com/ticket/25627 - Django is swallowing
ImportErrors in migrations for modules containing the string 'south' (fixed)
https://code.djangoproject.com/ticket/25637 - Add label and hostname length
validation in URLValidator (accepted)
https://code.djangoproject.com/ticket/25635 - URLValidator regex is not
allowing '+' character in scheme (accepted)
https://code.djangoproject.com/ticket/25642 - creating a model named
"order" cause sqlite database to crash (worksforme)
https://code.djangoproject.com/ticket/25644 - Setting a cookie after
deletion should not keep 1970 as expiry date (accepted)
https://code.djangoproject.com/ticket/25652 - Provide a more generic way to
test different browsers in selenium tests (created)
https://code.djangoproject.com/ticket/25653 - Provide a way to run only the
selenium tests (created)
Authored
https://github.com/django/django/pull/5482 - Fixed #25611 -- Standardized
descriptor signatures.
https://github.com/django/django/pull/5484 - Fixed #25596 -- Fixed
regression in password change view with custom user model.
https://github.com/django/django/pull/5485 - Fixed #25597 -- Fixed crash
with SplitArrayField and IntegerField on invalid value.
https://github.com/django/django/pull/5506 - Fixed #25100 -- Documented an
upgrade caveat for contenttypes migration.
https://github.com/django/django/pull/5507 - Fixed #25489 -- Documented
that SESSION_SAVE_EVERY_REQUEST doesn't create empty sessions.
https://github.com/django/django/pull/5508 - Fixed #23985 -- Documented a
backwards incompatible change in URLValidator.
https://github.com/django/django/pull/5509 - Fixed #25290 -- Warned against
modifying objects created in setUpTestData() in tests.
https://github.com/django/django/pull/5510 - Fixed #24019 -- Fixed
inaccurate docs about GenericRelation not supporting aggregation.
https://github.com/django/django/pull/5511 - Fixed #10045 -- Corrected docs
about .annotate()/.filter() ordering.
Reviewed/committed
--
https://github.com/django/django/pull/5481 - Fixed #25610 -- Reverted
removal of request.current_app in {% url %} tag.
https://github.com/django/django/pull/5475 - Fixed #25441 -- Added support
for negative filesize to filesizeformat template filter.
https://github.com/django/django/pull/5492 - Fixed #21516 -- Updated
imports paths for some formset functions/classes.
https://github.com/django/django/pull/5220 - Fixed #20846 -- Increased
User.username max_length to 254 characters.
https://github.com/django/django/pull/5498 - Fixed #25620 -- Made
URLValidator prohibit URLs with consecutive dots in the domain section.
https://github.com/django/django/pull/5504 - Fixed #25635 -- Made
URLValidator allow '+' in scheme.
Reviews of core dev work
https://code.djangoproject.com/ticket/16734 - Fixed #16734 -- Set script
prefix in django.setup() to allo
Feature proposal: selection of views and tables for inspectdb
Hi there.
I have an Oracle database that I access from Django with a user with
limited privileges that can access some special views the DBA has set up
for me. I wanted to use inspectdb to automatically generate the models for
those views, but it didn't work.
The problem is that the SQL statement that Django uses to fetch the tables
and views [1] for the current user does not properly return the views I
need because the user does not own them, and USER_VIEWS only returns those
VIEWS owned by the user. Not owning a table or a view should not be an
obstacle for automatically generating a model, so my proposal is to extend
the inspectdb to allow selecting what tables and views should be considered
for inspection. This would enable the inspection of tables and/or views
that the user does not own, as long as their name is known.
It would be very easy to do, just add an optional positional argument to
the inspectdb commands for the names of the tables/views and, if it's
available, just inspect those tables/views instead of those returned by the
introspection service.
Here's a patch of a possible solution:
--- django/django/core/management/commands/inspectdb.py 2015-10-31
20:50:57.401113597 +0100
+++
/home/jose/.virtualenvs/ori2/lib/python3.4/site-packages/django/core/management/commands/inspectdb.py
2015-10-31
20:52:26.241112474 +0100
@@ -19,6 +19,8 @@
parser.add_argument('--database', action='store', dest='database',
default=DEFAULT_DB_ALIAS, help='Nominates a database to '
'introspect. Defaults to using the "default" database.')
+parser.add_argument('table', action='store', nargs='*', type=str,
+help='Selects what tables or views should be
introspected')
def handle(self, **options):
try:
@@ -50,7 +51,12 @@
yield ''
yield 'from %s import models' % self.db_module
known_models = []
-for table_name in connection.introspection.table_names(cursor):
+if options['table']:
+tables_to_introspect = options['table']
+else:
+tables_to_introspect =
connection.introspection.table_names(cursor)
+
+for table_name in tables_to_introspect:
if table_name_filter is not None and
callable(table_name_filter):
if not table_name_filter(table_name):
continue
Regards
P.S.: sorry if I messed up any rule of the contribution guidelines, I'm not
used to contributing to large open source projects.
[1]
https://github.com/django/django/blob/master/django/db/backends/oracle/introspection.py#L54
--
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/e05210bc-919e-4d9b-94a6-a86f51ff2132%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Feature proposal: selection of views and tables for inspectdb
Hi José,
Can I just clarify the problem for a second.
Are you saying that inspectdb isn't returning output for tables owned by a
separate user but visible to the django User? If so, there's an argument to
be made about correcting that behaviour and just generating everything
visible. Of course there's probably good arguments against that also (I had
an app that did that for a schema which had way too much permission --
startup took hours as it inspected nearly the entire db cluster). There's
also considerations about how to view these tables/views as they will
probably require a schema prefix "otheruser.sometable" which Django doesn't
really support.
Your proposal to limit the table/views is a decent one, and should be
considered independent of the problem above I think.
You can open a ticket on trac for each of these ideas
here https://code.djangoproject.com/newticket and they can be triaged and
debated there. If a rough consensus can't be reached then the discussion
can moved back here. You can also create a Pull Request on Github with the
patch above for the limit tables ticket. Seeing code alongside a feature
request goes a long way!
Django has quite a lot of text around
contributions: https://docs.djangoproject.com/en/dev/internals/contributing/
so feel free to have a scan of that page for appropriate details. There
should be nothing too outrageous though.
Cheers!
On Sunday, 1 November 2015 15:52:46 UTC+11, José Tomás Tocino wrote:
>
> Hi there.
>
> I have an Oracle database that I access from Django with a user with
> limited privileges that can access some special views the DBA has set up
> for me. I wanted to use inspectdb to automatically generate the models for
> those views, but it didn't work.
>
> The problem is that the SQL statement that Django uses to fetch the tables
> and views [1] for the current user does not properly return the views I
> need because the user does not own them, and USER_VIEWS only returns those
> VIEWS owned by the user. Not owning a table or a view should not be an
> obstacle for automatically generating a model, so my proposal is to extend
> the inspectdb to allow selecting what tables and views should be considered
> for inspection. This would enable the inspection of tables and/or views
> that the user does not own, as long as their name is known.
>
> It would be very easy to do, just add an optional positional argument to
> the inspectdb commands for the names of the tables/views and, if it's
> available, just inspect those tables/views instead of those returned by the
> introspection service.
>
> Here's a patch of a possible solution:
>
> --- django/django/core/management/commands/inspectdb.py 2015-10-31
> 20:50:57.401113597 +0100
> +++
> /home/jose/.virtualenvs/ori2/lib/python3.4/site-packages/django/core/management/commands/inspectdb.py
> 2015-10-31
> 20:52:26.241112474 +0100
> @@ -19,6 +19,8 @@
> parser.add_argument('--database', action='store', dest='database',
> default=DEFAULT_DB_ALIAS, help='Nominates a database to '
> 'introspect. Defaults to using the "default" database.')
> +parser.add_argument('table', action='store', nargs='*', type=str,
> +help='Selects what tables or views should be
> introspected')
>
> def handle(self, **options):
> try:
> @@ -50,7 +51,12 @@
> yield ''
> yield 'from %s import models' % self.db_module
> known_models = []
> -for table_name in
> connection.introspection.table_names(cursor):
> +if options['table']:
> +tables_to_introspect = options['table']
> +else:
> +tables_to_introspect =
> connection.introspection.table_names(cursor)
> +
> +for table_name in tables_to_introspect:
> if table_name_filter is not None and
> callable(table_name_filter):
> if not table_name_filter(table_name):
> continue
>
> Regards
>
> P.S.: sorry if I messed up any rule of the contribution guidelines, I'm
> not used to contributing to large open source projects.
>
> [1]
> https://github.com/django/django/blob/master/django/db/backends/oracle/introspection.py#L54
>
--
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/c6f9547e-baa7-4625-906b-b45d33f883c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
