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

[Shai Berger]

Hi José,

On Tuesday 03 November 2015 12:58:54 José Tomás Tocino wrote:
> El lunes, 2 de noviembre de 2015, 13:22:17 (UTC+1), Shai Berger escribió:
> > https://code.djangoproject.com/ticket/6148
>
> That ticket seems somewhat related, but the feature we're dealing with here
> is, in my opinion, much simpler and easier to accomplish than the one
> mentioned in the ticket. What do you think?
> 
There are several points that come to mind:

1) Some progress has been made on the "support schemas" ticket lately, and I 
believe that completing that ticket may affect the way this feature is 
implemented. For example, with good schema support, it seems reasonable to 
take one argument -- the name of the schema to introspect. I'd hesitate to 
accept the feature as suggested without considering such possibilities.

2) In order to be useful to you, it is not enough to introspect the models -- 
you need to be able to use them as well. That is, essentially, ticket 6148 
without migrations, unless I am missing something.

To prove me wrong and/or encounter the further problems, there's two things 
you can do:

a) Create the relevant models manually, and try to use them from your 
application. Traditionally, this has been done by providing a quoted name with 
a schema as table name -- something like

class MyModel(Model):
class Meta:
table_name = '"schema"."view"'

b) Add a test that introspects a table from another schema. On Oracle, 
creating tables in another schema is probably too hard to do in a test, but 
you can try to introspect views from INFORMATION_SCHEMA (with a little care 
and luck, you may even be able to write a test that should work on all 
backends, as INFORMATION_SCHEMA is standardized).

> BTW, yesterday I added the docs and release notes to the
> PR https://github.com/django/django/pull/5530#issuecomment-152960635
> 

3) 1.9 is feature-frozen at this point -- its beta is out already. Even if the 
feature is accepted as-is, it would need to target 1.10.

HTH,
Shai.

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

[José Tomás Tocino García]

Hi Shai

First of all, I'd like to point out that I don't have experience working
with different schemas, so bear with me if I don't fully comprehend the
ticket you've referenced.

1) Some progress has been made on the "support schemas" ticket lately, and I
> believe that completing that ticket may affect the way this feature is
> implemented. For example, with good schema support, it seems reasonable to
> take one argument -- the name of the schema to introspect. I'd hesitate to
> accept the feature as suggested without considering such possibilities.
>

But we would be running into the same problem: we would not be able to
select individual tables or views to introspect, but entire schemas. If we
had support, I think it'd be trivial to add an optional argument to
inspectdb to select the schema to be introspected.


> 2) In order to be useful to you, it is not enough to introspect the models
> --
> you need to be able to use them as well. That is, essentially, ticket 6148
> without migrations, unless I am missing something.
>

Maybe I don't understand you, but I'm actually able to use the models
generated with my patch. Queries are executed properly. Is that what you
mean?

b) Add a test that introspects a table from another schema. On Oracle,
> creating tables in another schema is probably too hard to do in a test, but
> you can try to introspect views from INFORMATION_SCHEMA (with a little care
> and luck, you may even be able to write a test that should work on all
> backends, as INFORMATION_SCHEMA is standardized).
>

Honestly, I still fail to see what this has to do with my particular patch.

I feel like this is getting overcomplicated, I just wanted to add an option
to an already existing management command, that's it, nothing fancy :-/


> 3) 1.9 is feature-frozen at this point -- its beta is out already. Even if
> the
> feature is accepted as-is, it would need to target 1.10.
>

I've restored the release notes for 1.9 and added the info on the 1.10
version.



-- 
José Tomás Tocino García
http://www.josetomastocino.com

-- 
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/CAAOwDo5p%2BPbd7%3DzL6jKwqpGgJDyxpoLsfg2TCVntodJGA_zFWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Allen]

Since we're on the topic, it'd be great if `inspectdb` also accepted a 
`--tables` option, to only move certain tables in the database. For example:

./manage.py inspectdb --tables=form_*,user_*

...to import any tables starting with 'form_' or 'user_'. Allow with the 
`--database` option, this would allow moving over certain features 
app-by-app more easily when migrating a large project, without having to do 
a "dump all, remove cruft", which can be time consuming with very large 
legacy systems.

Regards,

Tim

On Sunday, November 1, 2015 at 12:52:46 AM UTC-4, 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/cf7ca8ac-b1a7-46ad-9ec9-41a7cccedfb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shai Berger]

Just to make sure we're talking about the same thing:

Are you doing something like "inspectdb other.a other.b" or "inspectdb a b"?

I was writing assuming the first.

Beyond that -- the attitude we've always taken with inspectdb is to just make 
it get all the tables, and let the user delete models they don't need (the 
output is usually not exactly correct anyway).

To make it clear: I (and Josh, AFAICT) was not responding about an option to 
limit the set of tables introspected, but about an option to introspect tables 
which weren't introspected before. If your intention is to just limit, that's 
a different story.

And I'm sorry if I make it seem complicated -- the reservation I have is that 
I think selecting schemas to introspect would be more useful than selecting 
tables, and so I don't want the positional arguments to be "captured" for 
tables.

HTH,
Shai.

On Wednesday 04 November 2015 16:15:00 José Tomás Tocino García wrote:
> Hi Shai
> 
> First of all, I'd like to point out that I don't have experience working
> with different schemas, so bear with me if I don't fully comprehend the
> ticket you've referenced.
> 
> 1) Some progress has been made on the "support schemas" ticket lately, and
> I
> 
> > believe that completing that ticket may affect the way this feature is
> > implemented. For example, with good schema support, it seems reasonable
> > to take one argument -- the name of the schema to introspect. I'd
> > hesitate to accept the feature as suggested without considering such
> > possibilities.
> 
> But we would be running into the same problem: we would not be able to
> select individual tables or views to introspect, but entire schemas. If we
> had support, I think it'd be trivial to add an optional argument to
> inspectdb to select the schema to be introspected.
> 
> > 2) In order to be useful to you, it is not enough to introspect the
> > models --
> > you need to be able to use them as well. That is, essentially, ticket
> > 6148 without migrations, unless I am missing something.
> 
> Maybe I don't understand you, but I'm actually able to use the models
> generated with my patch. Queries are executed properly. Is that what you
> mean?
> 
> b) Add a test that introspects a table from another schema. On Oracle,
> 
> > creating tables in another schema is probably too hard to do in a test,
> > but you can try to introspect views from INFORMATION_SCHEMA (with a
> > little care and luck, you may even be able to write a test that should
> > work on all backends, as INFORMATION_SCHEMA is standardized).
> 
> Honestly, I still fail to see what this has to do with my particular patch.
> 
> I feel like this is getting overcomplicated, I just wanted to add an option
> to an already existing management command, that's it, nothing fancy :-/
> 
> > 3) 1.9 is feature-frozen at this point -- its beta is out already. Even
> > if the
> > feature is accepted as-is, it would need to target 1.10.
> 
> I've restored the release notes for 1.9 and added the info on the 1.10
> version.

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

[José Tomás Tocino García]

>
> Are you doing something like "inspectdb other.a other.b" or "inspectdb a
> b"?
>

The latter. Given a single database (and the default schema), my patch
allows to just inspect tables "a" and "b".


> Beyond that -- the attitude we've always taken with inspectdb is to just
> make
> it get all the tables, and let the user delete models they don't need (the
> output is usually not exactly correct anyway).
>

The problem is what I mentioned in my first message, the current
implementation of inspectdb fails to get all the tables and views when the
user does not own them. Therefore, if I launch inspectdb as-is, I don't get
any models generated, because the introspection method used to fetch the
tables and views does not return any element not owned by the user.


> To make it clear: I (and Josh, AFAICT) was not responding about an option
> to
> limit the set of tables introspected, but about an option to introspect
> tables
> which weren't introspected before. If your intention is to just limit,
> that's
> a different story.
>

My intention is just that, to be able to limit what tables are introspected
when inspectdb is launched, regardless of what has been inspected before.


> And I'm sorry if I make it seem complicated -- the reservation I have is
> that
> I think selecting schemas to introspect would be more useful than selecting
> tables, and so I don't want the positional arguments to be "captured" for
> tables.
>

Well, selecting a schema would be a plausible usecase, the one I propose is
a different one — a valid one as well, IMHO. I don't think they should
conflict with each other, just let the user decide.



>
> HTH,
> Shai.
>
> On Wednesday 04 November 2015 16:15:00 José Tomás Tocino García wrote:
> > Hi Shai
> >
> > First of all, I'd like to point out that I don't have experience working
> > with different schemas, so bear with me if I don't fully comprehend the
> > ticket you've referenced.
> >
> > 1) Some progress has been made on the "support schemas" ticket lately,
> and
> > I
> >
> > > believe that completing that ticket may affect the way this feature is
> > > implemented. For example, with good schema support, it seems reasonable
> > > to take one argument -- the name of the schema to introspect. I'd
> > > hesitate to accept the feature as suggested without considering such
> > > possibilities.
> >
> > But we would be running into the same problem: we would not be able to
> > select individual tables or views to introspect, but entire schemas. If
> we
> > had support, I think it'd be trivial to add an optional argument to
> > inspectdb to select the schema to be introspected.
> >
> > > 2) In order to be useful to you, it is not enough to introspect the
> > > models --
> > > you need to be able to use them as well. That is, essentially, ticket
> > > 6148 without migrations, unless I am missing something.
> >
> > Maybe I don't understand you, but I'm actually able to use the models
> > generated with my patch. Queries are executed properly. Is that what you
> > mean?
> >
> > b) Add a test that introspects a table from another schema. On Oracle,
> >
> > > creating tables in another schema is probably too hard to do in a test,
> > > but you can try to introspect views from INFORMATION_SCHEMA (with a
> > > little care and luck, you may even be able to write a test that should
> > > work on all backends, as INFORMATION_SCHEMA is standardized).
> >
> > Honestly, I still fail to see what this has to do with my particular
> patch.
> >
> > I feel like this is getting overcomplicated, I just wanted to add an
> option
> > to an already existing management command, that's it, nothing fancy :-/
> >
> > > 3) 1.9 is feature-frozen at this point -- its beta is out already. Even
> > > if the
> > > feature is accepted as-is, it would need to target 1.10.
> >
> > I've restored the release notes for 1.9 and added the info on the 1.10
> > version.
>



-- 
José Tomás Tocino García
http://www.josetomastocino.com

-- 
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/CAAOwDo6HzqOS1TPWmNnHxJAKhJyP3vBzV6GfFw9oNArPnCzBKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shai Berger]

On Wednesday 04 November 2015 16:46:35 José Tomás Tocino García wrote:
> > Are you doing something like "inspectdb other.a other.b" or "inspectdb a
> > b"?
> 
> The latter. Given a single database (and the default schema), my patch
> allows to just inspect tables "a" and "b".
> 

Now I get it. There are tables in your schema, which are not owned by you. 
Frankly, I wasn't aware this was possible.

> 
> The problem is what I mentioned in my first message, the current
> implementation of inspectdb fails to get all the tables and views when the
> user does not own them.

In that case, are you sure what you're offering is a solution and not just a 
workaround? Shouldn't we make it so that inspectdb always gets all the tables 
in the schema?

> 
> My intention is just that, to be able to limit what tables are introspected
> when inspectdb is launched, regardless of what has been inspected before.
> 

What do you thunk of Tim Allen's suggestion:

./manage.py inspectdb --tables=form_*,user_*

Thanks for your patience in this,

Shai.

[ANNOUNCE] Django bugfix release issued: 1.8.6

[Tim Graham]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2015/nov/04/bugfix-release-issued/

-- 
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/cc53d42d-d775-4a7e-a936-cd29e2608e44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[José Tomás Tocino García]

>
> In that case, are you sure what you're offering is a solution and not just
> a
> workaround? Shouldn't we make it so that inspectdb always gets all the
> tables
> in the schema?
>

Well, as far as I'm concerned, I'd rather be able to choose what tables I
want to work with. In fact, I'm not sure it's possible to know all the
accessible tables/views for a single user in Oracle — at least in a way
that doesn't return a myriad of built-in tables and views unrelated to my
needs.


> >
> > My intention is just that, to be able to limit what tables are
> introspected
> > when inspectdb is launched, regardless of what has been inspected before.
> >
>
> What do you thunk of Tim Allen's suggestion:
>
> ./manage.py inspectdb --tables=form_*,user_*
>
>
Well, inspectdb already does that. There's a shadow option
called table_name_filter that is used by tests and does exactly that,
filter the tables/views according to a given filtering function (usually
one that checks whether the name starts with a string). The only problem is
that it's not available to be used from the manage.py command line, because
it needs you to use Python to write the filtering function. For example:

call_command('inspectdb',
 table_name_filter=lambda tn:
tn.startswith('inspectdb_'),
 stdout=out)

In the tests, the table_name_filter option is always filled with a function
that checks the beginning of the table name.

The suggestion is certainly interesting and kind of goes hand in hand with
mine. The problem I still see is what I mentioned before: how to get all
the views and tables that can be read by the user so you can filter them.
These are two different beasts I'm afraid.

Regards.


-- 
José Tomás Tocino García
http://www.josetomastocino.com

-- 
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/CAAOwDo5Ouabie7KeO17tRMmChuT2ZdfJjK9BO%3DfYhmsczsUP1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

An issue with Django 1.8.6 support for south migrations

[David Filipovic]

I have initially created the ticket 
https://code.djangoproject.com/ticket/25618 which addressed the bug that 
would occur if south migrations somehow ended up being still present in the 
migrations module.

According to a report in: 
https://code.djangoproject.com/ticket/25618#comment:7, this seems to break 
certain third party apps, in particular:

* non-upgraded apps that retained south migrations in the migrations 
module but have not introduced Django migrations. An example of such an app 
is `django-extensions`

Personally, I think, these apps haven't really supported Django past Django 
1.6.x and if they claimed they did, it was a misconception on their part.


However, in order not to break any apps that might have done this, I 
created a new pull request, that fixes this problem in a way that will not 
cause this issue.


I wanted to check what people thought here regarding whether this should be 
incorporated or not?
Should we make those apps fail and have them fully upgrade to support 1.7+, 
or should we address this and let them silently keep the south migrations?

-- 
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/99820cef-4404-40aa-97f8-4d3acace0a3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Marcin Nowak]

On Tuesday, November 3, 2015 at 5:17:32 PM UTC+1, Asif Saifuddin wrote:
>
> I would like to create an experiemental repo on my github for 
> experiementing the sqla support to django orm, hence some useful resource 
> indicator would be great. sqla have core engine and orm on top of it, so 
> the idea way to start experiment should be based on core?
>
>
I would like to contribute. But I'm afraid about all things dependent on 
DjangoORM, like migrations,admin,(model) forms and so on.
I like Django, most of it`s features and simplicity, but not DB layer 
(incl. migrations), html-related forms nor system checks.

There are several ways I think:

   - fork of Django (a new project based on good things), with some 
   compatibility layer
   - brand new framework based on great Werkzeug and SqlAlchemy, with 
   good-things picked from Django
   - switching to Flask (there is SqlAlchemy ext)

The last is the simplest :)

Cheers,
Marcin

-- 
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/95130c0c-d113-4e7f-9c8d-56459fd796b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hei,

I tried several frameworks, but django is my favorite for many reason. I
have some familarities with django internal code and mechanism.  sqlalchemy
integration with django is a challenging task as dj admin and forms and
some other thinks need to be figure out.

Cheers
Asif

On Thu, Nov 5, 2015 at 6:30 AM, Marcin Nowak 
wrote:

>
>
> On Tuesday, November 3, 2015 at 5:17:32 PM UTC+1, Asif Saifuddin wrote:
>>
>> I would like to create an experiemental repo on my github for
>> experiementing the sqla support to django orm, hence some useful resource
>> indicator would be great. sqla have core engine and orm on top of it, so
>> the idea way to start experiment should be based on core?
>>
>>
> I would like to contribute. But I'm afraid about all things dependent on
> DjangoORM, like migrations,admin,(model) forms and so on.
> I like Django, most of it`s features and simplicity, but not DB layer
> (incl. migrations), html-related forms nor system checks.
>
> There are several ways I think:
>
>- fork of Django (a new project based on good things), with some
>compatibility layer
>- brand new framework based on great Werkzeug and SqlAlchemy, with
>good-things picked from Django
>- switching to Flask (there is SqlAlchemy ext)
>
> The last is the simplest :)
>
> Cheers,
> Marcin
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/puVGMV7GlNE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/95130c0c-d113-4e7f-9c8d-56459fd796b1%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKAqTgpe9Ke0TiGxLXfST4%2BpAOpJDGqdq%3D%3DhDS%2Bhm90L9WuJCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Russell Keith-Magee]

Hi Asif,

On Wed, Nov 4, 2015 at 12:17 AM, Asif Saifuddin  wrote:

> I would like to create an experiemental repo on my github for
> experiementing the sqla support to django orm, hence some useful resource
> indicator would be great. sqla have core engine and orm on top of it, so
> the idea way to start experiment should be based on core?
>

I gave a broad description of what this would look like in my DjangoCon US
presentation:

https://www.youtube.com/watch?v=VgM0qmpHDiE&list=PLE7tQUdRKcyaRCK5zIQFW-5XcPZOE-y9t&index=10

The answer is to write an adaptor for SQLAlchemy so that it can “quack”
like Django’s Meta model, which will then make it compatible with Django’s
Admin and Forms.

Yours,
Russ Magee %-)

-- 
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/CAJxq84_e8EnrxkBUuYLHYP8dHD2J5vcB0Jh35uJDB%2Bjjt4s_GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

that's an awsome link :)

thanks russ.

On Thu, Nov 5, 2015 at 12:03 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> Hi Asif,
>
> On Wed, Nov 4, 2015 at 12:17 AM, Asif Saifuddin  wrote:
>
>> I would like to create an experiemental repo on my github for
>> experiementing the sqla support to django orm, hence some useful resource
>> indicator would be great. sqla have core engine and orm on top of it, so
>> the idea way to start experiment should be based on core?
>>
>
> I gave a broad description of what this would look like in my DjangoCon US
> presentation:
>
>
> https://www.youtube.com/watch?v=VgM0qmpHDiE&list=PLE7tQUdRKcyaRCK5zIQFW-5XcPZOE-y9t&index=10
>
> The answer is to write an adaptor for SQLAlchemy so that it can “quack”
> like Django’s Meta model, which will then make it compatible with Django’s
> Admin and Forms.
>
> Yours,
> Russ Magee %-)
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/puVGMV7GlNE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJxq84_e8EnrxkBUuYLHYP8dHD2J5vcB0Jh35uJDB%2Bjjt4s_GQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKAqTgrGRGwwnbs2wMonKFS8YgbcXOGO%2B%2BeW55bT-xMvHZvgjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jani Tiainen]

It's actually quite common pattern in Oracle to create tables using 
special admin user and then create separate users that just do have 
spesific priviledges per table.


Specially old Oracle docs promoted such a pattern.

In my opinion current behavior is just fine. Also I think inspectdb 
doesn't actually see any views, just tables.


On 04.11.2015 18:26, Shai Berger wrote:

On Wednesday 04 November 2015 16:46:35 José Tomás Tocino García wrote:

Are you doing something like "inspectdb other.a other.b" or "inspectdb a
b"?

The latter. Given a single database (and the default schema), my patch
allows to just inspect tables "a" and "b".


Now I get it. There are tables in your schema, which are not owned by you.
Frankly, I wasn't aware this was possible.


The problem is what I mentioned in my first message, the current
implementation of inspectdb fails to get all the tables and views when the
user does not own them.

In that case, are you sure what you're offering is a solution and not just a
workaround? Shouldn't we make it so that inspectdb always gets all the tables
in the schema?


My intention is just that, to be able to limit what tables are introspected
when inspectdb is launched, regardless of what has been inspected before.


What do you thunk of Tim Allen's suggestion:

./manage.py inspectdb --tables=form_*,user_*

Thanks for your patience in this,

Shai.


--
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/563B087F.3090607%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[José Tomás Tocino García]

>
> In my opinion current behavior is just fine.


How is it "just fine" if there are usecases (the one I've described, for
instance) where the current behavior evidently doesn't cut it?


>
>
> On 04.11.2015 18:26, Shai Berger wrote:
>
>> On Wednesday 04 November 2015 16:46:35 José Tomás Tocino García wrote:
>>
>>> Are you doing something like "inspectdb other.a other.b" or "inspectdb a
 b"?

>>> The latter. Given a single database (and the default schema), my patch
>>> allows to just inspect tables "a" and "b".
>>>
>>> Now I get it. There are tables in your schema, which are not owned by
>> you.
>> Frankly, I wasn't aware this was possible.
>>
>> The problem is what I mentioned in my first message, the current
>>> implementation of inspectdb fails to get all the tables and views when
>>> the
>>> user does not own them.
>>>
>> In that case, are you sure what you're offering is a solution and not
>> just a
>> workaround? Shouldn't we make it so that inspectdb always gets all the
>> tables
>> in the schema?
>>
>> My intention is just that, to be able to limit what tables are
>>> introspected
>>> when inspectdb is launched, regardless of what has been inspected before.
>>>
>>> What do you thunk of Tim Allen's suggestion:
>>
>> ./manage.py inspectdb --tables=form_*,user_*
>>
>> Thanks for your patience in this,
>>
>> Shai.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/CuczZovhp74/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/563B087F.3090607%40gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
José Tomás Tocino García
http://www.josetomastocino.com

-- 
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/CAAOwDo5ACkgXcwig1dpd4u_mdDPCe9gvfNyHue%2BbyNaN1n-qog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.