Re: Feature proposal: selection of views and tables for inspectdb

2015-11-02 Thread Shai Berger
Hi,

I haven't looked at your PR yet, but this seems related to this old ticket:
https://code.djangoproject.com/ticket/6148

Have fun,
Shai.

On Monday 02 November 2015 02:04:32 José Tomás Tocino wrote:
> Hi Josh.
> 
> That's exactly what I'm saying. According to the Oracle docs [1],
> USER_VIEWS describes the views owned by the current user, but the views I'm
> concerned with are only SELECT-able by the user, that has been granted
> access using:
> 
> GRANT SELECT ON UXXIAC.SOMEVIEW TO MY_USER;
> 
> I'm not experienced with Oracle at all, but a quick Google search aims at a
> possible solution [2] to list all accessible views, not only those owned by
> the user. Maybe that could be a possible replacement, I'll check it with
> the database I'm working with tomorrow (today's a holiday here in Spain).
> 
> I've opened a ticket in Trac regarding the selection of views and tables to
> be inspected (https://code.djangoproject.com/ticket/25658#ticket) and a
> pull request with the code (https://github.com/django/django/pull/5530).
> 
> Regards.
> 
> 
> [1]
> http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4489.htm#RE
> FRN26305 [2] http://stackoverflow.com/a/13742917/276451
> 
> El domingo, 1 de noviembre de 2015, 6:48:09 (UTC+1), Josh Smeaton escribió:
> > 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/man
> >> agement/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 '

L118 errros

2015-11-02 Thread Jose Paul
I am getting following errors when I am tried DJango 1.8 test cases against 
DB2 .What can be the cause for this ?.
Can someone comment on this please .

==
FAIL: test_decimal_numbers (utils_tests.test_numberformat.TestNumberFormat)
--
Traceback (most recent call last):
  File 
"C:\Users\IBM_ADMIN\PythonWorkspace\DJangoTestCases\src\DJangoTestCases\tests\utils_tests\test_numberformat.py",
 
line 56, in test_decimal_numbers
self.assertEqual(nformat(Decimal('1234'), '.', grouping=2, 
thousand_sep=','), '1234')
AssertionError: '12,34' != '1234'

==
FAIL: test_format_number (utils_tests.test_numberformat.TestNumberFormat)
--
Traceback (most recent call last):
  File 
"C:\Users\IBM_ADMIN\PythonWorkspace\DJangoTestCases\src\DJangoTestCases\tests\utils_tests\test_numberformat.py",
 
line 14, in test_format_number
self.assertEqual(nformat(1234, '.', grouping=2, 
thousand_sep=','),'1234')
AssertionError: u'12,34' != '1234'

==
FAIL: test_format_string (utils_tests.test_numberformat.TestNumberFormat)
--
Traceback (most recent call last):
  File 
"C:\Users\IBM_ADMIN\PythonWorkspace\DJangoTestCases\src\DJangoTestCases\tests\utils_tests\test_numberformat.py",
 
line 23, in test_format_string
self.assertEqual(nformat('1234', '.', grouping=2, 
thousand_sep=','),'1234')
AssertionError: u'12,34' != '1234'

-- 
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/a98eb7de-2aa4-415e-bb0f-fc3b0926d306%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.