Re: Proposal: Tutorial Refresh

[Jani Tiainen]

Russell Keith-Magee kirjoitti:
> On Fri, Oct 9, 2009 at 11:22 PM, Jacob Kaplan-Moss  wrote:
>> On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson  wrote:
>>> * How do people feel about a tutorial that covers a complete site?
>> Well, in grand Django tradition, by suggesting this, you've
>> volunteered to be in charge :)
>>
>> But sign me up as an editor (language and code), at least, and I'll
>> try to help out by writing some sections, too.
> 
> Hi Rob,
> 
> I started to write a reply too, and then realized I was just writing
> "hell yeah" after each of Jacob's paragraphs. So I decided to stop.
> :-)
> 
> The only point I though I would elaborate on is the specific example
> for the tutorial. I agree with Jacob's comment that a pastebin is a
> bit of an esoteric example. There's also value in diversity - every
> extra example is one more sample site people can use as a point of
> reference. Having 2 pastebin examples floating around the community
> doesn't help much, but having a pastebin and something else adds some
> value.
> 
> My immediate reaction was that a blog engine is the natural example.
> It allows you to expose date-based generic views. You can use
> contrib.comments. You could show integration with any number of 3rd
> party apps. You could even demonstrate the transition to Pinax. The
> problem space is well known and well understood. Plus,
> write-your-own-blog-engine is a running joke in the Django community.
> :-)

Time of my learning I wondered this part - why always blogs. I don't 
want to write blog engine... :)

> That said, Jacob's bikeshed comment is also completely accurate. You
> build it, you get to choose. There's also something to be said for
> having a tutorial that doesn't duplicate the capabilities of any
> number of existing pluggable applications.

I can also lend my small hand. I've recently (last spring) gone through 
learning curve how to use (Geo)Django and how to get at least decent 
(IMO) system up and running.

I live in world of GIS. My projects are not traditional web apps, like 
blogs, pastebins. Personally I found a bit hard to find information that 
goes much beyond standard blog engine or simple forum. Also few 
surprises came along the path to where I am now.

And of course got some "why this wasn't mentioned in tutorial" moments.

-- 
Jani Tiainen

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

#7539 Add ON DELETE and ON UPDATE support

[Jani Tiainen]

Is there anyone working for this ticket?

There seemed to be few patches but then a silence.

I would be interested in to help/implement that feature since it's very 
highly needed feature in our own code.

-- 
Jani Tiainen

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

Re: #7539 Add ON DELETE and ON UPDATE support

[Jani Tiainen]

Michael Glassford kirjoitti:
> 
> 
> Jani Tiainen wrote:
>> Is there anyone working for this ticket?
>>
>> There seemed to be few patches but then a silence.
>>
>> I would be interested in to help/implement that feature since it's very 
>> highly needed feature in our own code.
>>
> 
> I am. The silence is due to a couple of problems I've been looking into, 
> but I'm thinking of posting a patch with the problems and getting 
> suggestions on how to deal with them. Maybe later today.

Glad to hear and I'm pretty happy to help to test things (specially on 
Oracle DB).

-- 
Jani Tiainen

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

Re: #7539 Add ON DELETE and ON UPDATE support

[Jani Tiainen]

Michael Glassford kirjoitti:
> 
> 
> Alex Gaynor wrote:
> 
>> Can you upload it with a .diff extension so we can get proper code
>> highlighting on trac.
>>
>> Alex
>>
> 
> Sorry. Done.

I did a quick look and what I understand now it only supports client 
side on_delete actions (cascade, protect (restrict), set null and set 
default)?

I assume that None means not specified on_delete (old way). Could that 
translation to CASCADE or SET_NULL activity made in field construction 
phase? Or is there need to have explicitly define on_delete=None?

Only thing I'm a bit worried is a performance. I have model like 
following (legacy model):

class Device(models.Model):
 name = models.CharField()

class Connector(models.Model):
 device = models.ForeignKey(Device, on_delete=CASCADE)
 type = models.CharField()  

class Connection(models.Model):
 connector_1 = models.ForeignKey(Connector, on_delete=CASCADE)
 connector_2 = models.ForeignKey(Connector, on_delete=CASCADE)
 direction = models.CharField() 

class Route(models.Model):
 name = models.CharField()

class RouteConnection(models.Model):
 route = models.ForeignKey(Route, on_delete=PROTECT)
 connection = models.ForeignKey(Connection, on_delete=PROTECT)


Now I have one device that contains 1000 connectors. Each connection has 
at least 1 connection. And one connection has one route attached to it 
(using RouteConnection).

I want to delete this partical device.

In worst case does system need to traverse over all 999 connections 
before hitting one that says we can't delete device?

-- 
Jani Tiainen

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

Re: #7539 Add ON DELETE and ON UPDATE support

[Jani Tiainen]

Well we put that piece of code in test quite soon and see does it help 
or not. And if some problems arises in big deletes.

Usually it's just something like that you can't delete row from type 
table if it's in use.

Michael Glassford kirjoitti:
> 
> 
> Jani Tiainen wrote:
>> Michael Glassford kirjoitti:
>>> Alex Gaynor wrote:
>>>
>>>> Can you upload it with a .diff extension so we can get proper code
>>>> highlighting on trac.
>>>>
>>>> Alex
>>>>
>>> Sorry. Done.
>> I did a quick look and what I understand now it only supports client 
>> side on_delete actions (cascade, protect (restrict), set null and set 
>> default)?
> 
> Yes.
> 
>> I assume that None means not specified on_delete (old way). 
> 
> Yes.
> 
>  > Could that
>> translation to CASCADE or SET_NULL activity made in field construction 
>> phase? 
> 
>> Or is there need to have explicitly define on_delete=None?
> 
> No.
> 
>> Only thing I'm a bit worried is a performance. I have model like 
>> following (legacy model):
>>
>> class Device(models.Model):
>>  name = models.CharField()
>>
>> class Connector(models.Model):
>>  device = models.ForeignKey(Device, on_delete=CASCADE)
>>  type = models.CharField()   
>>
>> class Connection(models.Model):
>>  connector_1 = models.ForeignKey(Connector, on_delete=CASCADE)
>>  connector_2 = models.ForeignKey(Connector, on_delete=CASCADE)
>>  direction = models.CharField()  
>>
>> class Route(models.Model):
>>  name = models.CharField()
>>
>> class RouteConnection(models.Model):
>>  route = models.ForeignKey(Route, on_delete=PROTECT)
>>  connection = models.ForeignKey(Connection, on_delete=PROTECT)
>>
>>
>> Now I have one device that contains 1000 connectors. Each connection has 
>> at least 1 connection. And one connection has one route attached to it 
>> (using RouteConnection).
>>
>> I want to delete this partical device.
>>
>> In worst case does system need to traverse over all 999 connections 
>> before hitting one that says we can't delete device?
> 
> Unfortunately, yes. I realize that the ideal situation is to allow the 
> backend to handle this if it can, since it can do so more efficiently, 
> but I didn't think that feature could be ready for the Django 1.2. So I 
> decided that something is better than nothing and went for a phased 
> approach. I hope to add backend support in a later version of Django.
> 
> Mike
> 
> 
> > 


-- 
Jani Tiainen

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

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
> Hey all,
> 
> Russ and I have been working on getting the multi-db work ready for
> merge (final stretch here hopefully!), and I just ported the Oracle
> backend to the slightly updated backend arcitecture so it could use
> some testers.  If you've got an Oracle setup and can run some tests
> that would be great.  You can grab the code here:
> 
> http://github.com/alex/django/tree/multiple-db
> 
> Make sure you use the multiple-db branch.  I understand running the
> tests under Oracle can be a bit slow, so perhaps start by just running
> the "queries" tests, if they fail please reply with the complete
> tracebacks and such here, otherwise if you have the time a shot at
> running the full test suite would be great.
> 
> For GIS I'm fairly certain that's broken, however I'm not quite setup
> for running the GIS tests yet, therefore if you're set up for it and
> can run the tests please just reply with your tracebacks here
> (preferably with them on a pastebin like paste.pocoo.org though :))
> and I'll try to sort it out.
> 
> Thanks all,
> Alex
> 

We can try to run and experiment all that since we need multidb support
and we run Oracle with heavy GIS stuff. 

Is there any special requirements that I need to take account before
running tests?

-- 

Jani Tiainen



--

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

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
> Hey all,
> 
> Russ and I have been working on getting the multi-db work ready for
> merge (final stretch here hopefully!), and I just ported the Oracle
> backend to the slightly updated backend arcitecture so it could use
> some testers.  If you've got an Oracle setup and can run some tests
> that would be great.  You can grab the code here:
> 
> http://github.com/alex/django/tree/multiple-db
> 
> Make sure you use the multiple-db branch.  I understand running the
> tests under Oracle can be a bit slow, so perhaps start by just running
> the "queries" tests, if they fail please reply with the complete
> tracebacks and such here, otherwise if you have the time a shot at
> running the full test suite would be great.
> 

I did ran full test suite. First at maximum tablespace size must be 
set bit over 100MB (I changed it to 200MB but in tests I had peak of
102MB)

And then bunch of interesting errors:

==
ERROR: Multi-db fixtures are loaded correctly
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 467, in test_fixture_loading
title="Pro Django"
  File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
callableObj(*args, **kwargs)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 300, in get
num = len(clone)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 77, in __len__
self._result_cache = list(self.iterator())
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 234, in iterator
compiler = self.query.get_compiler(using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/sql/query.py",
line 148, in get_compiler
connection = connections[using]
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
68, in __getitem__
self.ensure_defaults(alias)
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
54, in ensure_defaults
raise ConnectionDoesNotExist("The connection %s doesn't exist" %
alias)
ConnectionDoesNotExist: The connection other doesn't exist

==
ERROR: Queries are constrained to a single database
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 100, in test_basic_queries
published=datetime.date(2009, 5, 4))
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 315, in create
obj.save(force_insert=True, using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 429, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 442, in save_base
connection = connections[using]
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
68, in __getitem__
self.ensure_defaults(alias)
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
54, in ensure_defaults
raise ConnectionDoesNotExist("The connection %s doesn't exist" %
alias)
ConnectionDoesNotExist: The connection other doesn't exist

==
ERROR: Objects created on the default database don't leak onto other
databases
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 34, in test_default_creation
Book.objects.get(title="Pro Django")
  File "/home/jtiai/src/django/multidb/django/db/models/manager.py",
line 119, in get
return self.get_query_set().get(*args, **kwargs)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 307, in get
% (self.model._meta.object_name, num, kwargs))
MultipleObjectsReturned: get() returned more than one Book -- it
returned 2! Lookup parameters were {'title': 'Pro Django'}

==
ERROR: Operations that involve sharing FK objects across databases
raise an error
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 391, in test_foreign_key_cross_database_protection
published=datetime.date(2009, 5, 4))
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 315, in create
obj.save(force_insert=True, using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 429, in save
self.save_base(using=using, force_insert=force_inser

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:

> 
> Thanks for taking the time to run all of those!  All of those
> ConnectionDoesNotExist errors come from the fact that the multidb
> tests expect you to have more than 1 DB set up in your settings file,
> the rigth solution here is probably to just fail right away, instead
> of attempting to run each individual test which can produce some
> confusing failures.  As for the other errors I'm not sure what's a
> consequence of my work, and what's an existing condition.  If you
> could run the trunk tests (with your modification for memory) and see
> what the result is that would be awesome.  Any new errors are
> obviously regressions and should be fixed.
> 
> Alex
> 

I didn't have to run anything, that what computers are for..? :)

Could you provide sample DATABASES connection definition for multidb
tests so I could rerun all that fancy stuff correctly.

-- 

Jani Tiainen



--

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

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Thu, 2009-11-26 at 01:44 -0600, Alex Gaynor wrote:
> On Thu, Nov 26, 2009 at 1:42 AM, Jani Tiainen  wrote:
> > On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:
> >
> >>
> >> Thanks for taking the time to run all of those!  All of those
> >> ConnectionDoesNotExist errors come from the fact that the multidb
> >> tests expect you to have more than 1 DB set up in your settings file,
> >> the rigth solution here is probably to just fail right away, instead
> >> of attempting to run each individual test which can produce some
> >> confusing failures.  As for the other errors I'm not sure what's a
> >> consequence of my work, and what's an existing condition.  If you
> >> could run the trunk tests (with your modification for memory) and see
> >> what the result is that would be awesome.  Any new errors are
> >> obviously regressions and should be fixed.
> >>
> >> Alex
> >>
> >
> > I didn't have to run anything, that what computers are for..? :)
> >
> > Could you provide sample DATABASES connection definition for multidb
> > tests so I could rerun all that fancy stuff correctly.
> >
> > --
> >
> > Jani Tiainen
> >
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en.
> >
> >
> >
> 
> DATABASES = {
> "default": {
> # your settings here
> },
> "other": {
> "ENGINE": "sqlite3",
> "NAME": ":memory:",
> }
> }
> 
> Is all you need (don't bother rerunning all of the tests with these
> settings, the only ones affected are the multiple_database ones).
> 
> Alex
> 

==
ERROR: Objects created on the default database don't leak onto other
databases
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 34, in test_default_creation
Book.objects.get(title="Pro Django")
  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/manager.py",
line 119, in get
return self.get_query_set().get(*args, **kwargs)
  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/query.py", line
307, in get
% (self.model._meta.object_name, num, kwargs))
MultipleObjectsReturned: get() returned more than one Book -- it
returned 2! Lookup parameters were {'title': 'Pro Django'}

==
FAIL: Queries are constrained to a single database
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 117, in test_basic_queries
self.assertRaises(Book.DoesNotExist,
Book.objects.using('default').get, published__year=2009)
AssertionError: DoesNotExist not raised

==
FAIL: Objects created on another database don't leak onto the default
database
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 76, in test_other_creation
title="Pro Django"
AssertionError: DoesNotExist not raised

--
Ran 12 tests in 2.778s

Well that's all for multiple_database tests configured so that "default"
points to my oracle and "other" points to sqlite3 memory database.


--

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

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Thu, 2009-11-26 at 20:23 +0800, Russell Keith-Magee wrote:
> On Thu, Nov 26, 2009 at 5:03 PM, Jani Tiainen  wrote:
> > On Thu, 2009-11-26 at 01:44 -0600, Alex Gaynor wrote:
> >> On Thu, Nov 26, 2009 at 1:42 AM, Jani Tiainen  wrote:
> >> > On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:
> >> >
> >> >>
> >> >> Thanks for taking the time to run all of those!  All of those
> >> >> ConnectionDoesNotExist errors come from the fact that the multidb
> >> >> tests expect you to have more than 1 DB set up in your settings file,
> >> >> the rigth solution here is probably to just fail right away, instead
> >> >> of attempting to run each individual test which can produce some
> >> >> confusing failures.  As for the other errors I'm not sure what's a
> >> >> consequence of my work, and what's an existing condition.  If you
> >> >> could run the trunk tests (with your modification for memory) and see
> >> >> what the result is that would be awesome.  Any new errors are
> >> >> obviously regressions and should be fixed.
> >> >>
> >> >> Alex
> >> >>
> >> >
> >> > I didn't have to run anything, that what computers are for..? :)
> >> >
> >> > Could you provide sample DATABASES connection definition for multidb
> >> > tests so I could rerun all that fancy stuff correctly.
> >> >
> >> > --
> >> >
> >> > Jani Tiainen
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Django developers" group.
> >> > To post to this group, send email to django-develop...@googlegroups.com.
> >> > To unsubscribe from this group, send email to 
> >> > django-developers+unsubscr...@googlegroups.com.
> >> > For more options, visit this group at 
> >> > http://groups.google.com/group/django-developers?hl=en.
> >> >
> >> >
> >> >
> >>
> >> DATABASES = {
> >> "default": {
> >> # your settings here
> >> },
> >> "other": {
> >> "ENGINE": "sqlite3",
> >> "NAME": ":memory:",
> >> }
> >> }
> >>
> >> Is all you need (don't bother rerunning all of the tests with these
> >> settings, the only ones affected are the multiple_database ones).
> >>
> >> Alex
> >>
> >
> > ==
> > ERROR: Objects created on the default database don't leak onto other
> > databases
> > --
> > Traceback (most recent call last):
> >  File
> > "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
> >  line 34, in test_default_creation
> >Book.objects.get(title="Pro Django")
> >  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/manager.py",
> > line 119, in get
> >return self.get_query_set().get(*args, **kwargs)
> >  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/query.py", line
> > 307, in get
> >% (self.model._meta.object_name, num, kwargs))
> > MultipleObjectsReturned: get() returned more than one Book -- it
> > returned 2! Lookup parameters were {'title': 'Pro Django'}
> >
> > ==
> > FAIL: Queries are constrained to a single database
> > --
> > Traceback (most recent call last):
> >  File
> > "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
> >  line 117, in test_basic_queries
> >self.assertRaises(Book.DoesNotExist,
> > Book.objects.using('default').get, published__year=2009)
> > AssertionError: DoesNotExist not raised
> >
> > ==
> > FAIL: Objects created on another database don't leak onto the default
> > database
> > --
> > Traceback (most recent call last):
> 

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Thu, Nov 26, 2009 at 5:44 PM, Ian Kelly  wrote:

> On Thu, Nov 26, 2009 at 8:38 AM, Russell Keith-Magee
>  wrote:
> > Yes - this does help. The confirms my suspicion - the problem is that
> > the fixture loaded in FixtureTestCase.test_fixture_loading isn't being
> > cleared before running the tests in QueryTestCase.
> >
> > The annoying thing is that I don't see this problem on any other
> > database, so there is something specific about transaction rollback on
> > Oracle. I can't see anything in that code that is should be
> > Oracle-specific behavior.
> >
> > The magic code is in _fixture_teardown(), starting at line 487 of
> > django/tests/testcases.py. That method *should* be resetting the
> > database at the end of multiple_database.FixtureTestCase, but
> > evidently it isn't. Either the transaction rollback code isn't getting
> > invoked, or it is getting invoked but not behaving as expected.
> >
> > Any debugging assistance you can provide here would be most welcome.
> >
> > Yours
> > Russ Magee %-)
>
> It sounds like you're running into another case of #11101.  The basic
> problem is that loading fixtures involves resetting sequences, which
> requires running DDL, which causes an implicit commit.
>
>
>
>
>
That must be it. Any DDL operation in Oracle does implicit commit before
actually execting DDL. Very hard to get around since it's how DDL works in
Oracle.

--

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

Re: Final call for feedback: Multi-db

[Jani Tiainen]

On Fri, Dec 18, 2009 at 9:43 AM, Russell Keith-Magee  wrote:

> Hi all,
>
> This is a second and final call for feedback on the multidb branch.
>
> Barring any objections or the discovery of major problems, my
> intention is to commit this early next week, hitting the alpha 1
> feature deadline by the skin of our collective teeth :-)
>
>
Haven't run any tests, but as a small request - I would be very happy that
you guys take a look ticket #11017 it's quite performance killer to some
selects on char fields (specially startswith) on Oracle.

--

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

Re: Oracle backend TextField unique=True error

[Jani Tiainen]

On Sun, 2009-12-20 at 22:25 -0800, Mario Briggs wrote:
> > This is known.  The Oracle notes [1] mention that TextFields cannot be
> > indexed.  Since Oracle requires indexes for unique columns, this also
> > means they cannot be unique, although we should probably make that
> > explicit.  It may also be worthwhile to check for this when the models
> > are validated.
> >
> > Ian
> >
> > [1] 
> > http://docs.djangoproject.com/en/1.1/ref/databases/#textfield-limitations
> 
> Ian,
> 
> From the other post on admin views using Text, it surfaced that Oracle
> (the DB) does support function based indexes on LOB upto ~4K. So the
> backend does not support that i guess ?
> 
> Unique index on Text, i agree with you.
> 
> Mario

Actually there could be a workaround. Limitation is that key in index
(return value of function) must be 4k or less. 

One workaround could be hashing + custom field (django side).

Or use function based hashed index:

10g and after:
create unique index my_lob_uq on my_table (ora_hash(my_lob));

and for 8 or 9i:
create unique index my_lob_uq on my_table
(DBMS_UTILITY.GET_HASH_VALUE(my_lob, 2,1048576));

-- 

Jani Tiainen


--

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

Re: Oracle backend TextField unique=True error

[Jani Tiainen]

On Mon, 2009-12-21 at 02:42 -0700, Ian Kelly wrote:
> On Sun, Dec 20, 2009 at 11:25 PM, Mario Briggs  
> wrote:
> >> This is known.  The Oracle notes [1] mention that TextFields cannot be
> >> indexed.  Since Oracle requires indexes for unique columns, this also
> >> means they cannot be unique, although we should probably make that
> >> explicit.  It may also be worthwhile to check for this when the models
> >> are validated.
> >>
> >> Ian
> >>
> >> [1] 
> >> http://docs.djangoproject.com/en/1.1/ref/databases/#textfield-limitations
> >
> > Ian,
> >
> > From the other post on admin views using Text, it surfaced that Oracle
> > (the DB) does support function based indexes on LOB upto ~4K. So the
> > backend does not support that i guess ?
> 
> Not currently, no.  And if I were to put in some work on improving on
> the Oracle backend's support for filtering on TextFields, I would
> concentrate first on fixing the query so that it correctly compares
> the entire TextField and not just the first 4000 characters.
> Unfortunately, I don't think any function-based index will help with
> that.

But there exists dbms_lob package to help with that, specially this
particular search case "dbms_lob.instr".

Of course it still has some issues (PL/SQL limitations) that may apply.

Oracle is very evil what comes to long text fields, there is just not
good and support for them.

-- 

Jani Tiainen

--

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

Bug #11017: Oracle LIKEC query doesn't use index

[Jani Tiainen]

Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in
patchset 9.2.0.6 and any later version.

What comes to Oracle official support options for 9.2:
Premier Support Ends: 31-Jul-2007
Extended Support Ends: 30-Jul-2010

If any problem is encountered you're first required to upgrade to latest
patchset (9.2.0.8) before requesting further assistance from Oracle. And
Oracle has always advised to apply patchsets to db.

I have only 9.2.0.1, but bug should appear there and I've patchsets for
9.2.0.6 and up so I can see does it really happen after upgrade. I can
stage and run tests to see was it that or something else. 

And known workaround (that works "everywhere") is use one I pasted few
ticket comment before.

It's more like design and support decision here - is there need to
support (obsolete) Oracle version(s)?

-- 

Jani Tiainen



--

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

Re: Bug #11017: Oracle LIKEC query doesn't use index

[Jani Tiainen]

On Tue, 2009-12-22 at 13:00 -0700, Ian Kelly wrote:
> On Tue, Dec 22, 2009 at 12:58 AM, Jani Tiainen  wrote:
> > Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in
> > patchset 9.2.0.6 and any later version.
> >
> > What comes to Oracle official support options for 9.2:
> > Premier Support Ends: 31-Jul-2007
> > Extended Support Ends: 30-Jul-2010
> >
> > If any problem is encountered you're first required to upgrade to latest
> > patchset (9.2.0.8) before requesting further assistance from Oracle. And
> > Oracle has always advised to apply patchsets to db.
> >
> > I have only 9.2.0.1, but bug should appear there and I've patchsets for
> > 9.2.0.6 and up so I can see does it really happen after upgrade. I can
> > stage and run tests to see was it that or something else.
> >
> > And known workaround (that works "everywhere") is use one I pasted few
> > ticket comment before.
> >
> > It's more like design and support decision here - is there need to
> > support (obsolete) Oracle version(s)?
> 
> Hi Jani,
> 
> The only thing I need before committing the workaround is for somebody
> to verify that the bug in #5985 is reproducible in version 9.2.0.5 or
> earlier, and that the workaround indeed fixes it.  Since I don't have
> an instance with the appropriate patchset available to test it myself,
> I'd appreciate it if you would do that testing.
> 
> I for one don't see a compelling case for dropping support for Oracle
> 9 yet.  If the workaround is successful, then the only Django feature
> currently not supported for Oracle 9 is the regex filter, and I'm not
> aware of anything on the horizon that will change that.  Oracle shops
> also tend to be notoriously slow at updating.  My employer is not as
> bad as some, but even we still have some Django installations running
> on Oracle 9.
> 
> Even if we do decide to drop support for Oracle 9 (or just the early
> patchsets thereof) soon, it will take a full release cycle so that we
> can issue the appropriate deprecation warnings.  We'll still want to
> be using the workaround at least for the short term.

Finally I managed to get a vm with Oracle 9.2.0.1, so are there some
specific tests I need to run? Is there patch that you would like to use
and I could apply and run tests again to see is there any regressions?

-- 

Jani Tiainen


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

Re: How to create a new command in django-admin.py

[Jani Tiainen]

23.2.2012 15:22, Johan kirjoitti:

Hi

I know how to create a new command in manage.py, this link explains it
nicely : 
https://docs.djangoproject.com/en/dev/howto/custom-management-commands/#command-objects
. But how do I create new command which would be available in django-
admin.py or in manage.py BUT without having to add the application to
the INSTALLED_APPS tuple?

Regards
Johan



Only way to achieve what you're asking is to modify Django source code - 
basically building in your command into Django core.


Is there real rationale to do that?

--

Jani Tiainen

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

Re: [GSoC 2012] Schema Alteration API proposal

[Jani Tiainen]

19.3.2012 13:15, Andrew Godwin kirjoitti:

On 19/03/12 11:08, Jonathan French wrote:

On 18 March 2012 23:33, Russell Keith-Magee mailto:russ...@keith-magee.com>> wrote:

> 2. An inspection tool that generates the appropriate python code
after
> inspecting models and current state of database.

The current consensus is that this shouldn't be Django's domain --
at least, not in the first instance. It might be appropriate to
expose an API to extract the current model state in a Pythonic form,
but a fully-fledged, user accessible "tool".




I would, however, definitely recommend not touching the Oracle or MSSQL
backends - three is already a lot of work, and they're harder databases
to get a hold of for testing.


Here I would like to rise my concern - specially being long time Django 
and Oracle user.. =)


First at all everyone can get hands on Oracle Express database, free of 
charge standard Django stuff works in it very well. Geodjango doesn't 
work with it. AFAIK MSSQL is something that is not officially supported 
by Django so that shouldn't be much a problem if it's not touched.


Secondly Django has been in the past very consistent in support of four 
databases: SQLite, PostgreSQL, MySQL and Oracle. All supported pretty 
well as well as possible. I'm aware that doing migrations for all 
databases is a time taking challenge to tackle around all peculiarities 
in different backends. So hopefully that consistency is kept even with 
new features like this.


And yes, second thing is of course Geodjango part which takes complexity 
to whole new level.


--

Jani Tiainen

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

Re: supported backends in core

[Jani Tiainen]

28.5.2012 15:35, Anssi Kääriäinen kirjoitti:

On May 28, 3:14 pm, Chris Northwood  wrote:

I believe PostGIS 2.0 isn't supported 
yet:https://code.djangoproject.com/ticket/16455


I added some comments to that ticket.

I am going to hijack this thread, and ask what is the status of Oracle
and spatialite support? Anybody running tests on these backends?
spatialite seems a bit hard to install, and Oracle GIS functionality
seems to be available only in the commercial versions.



Oracle has two different GIS functionalities Locator and Spatial. 
Locator is available for free and is subset of Spatial functionality.


Stupid thing is that you get full Spatial installed and you just have to 
know which feature belongs to what version. Top of that features 
included in Locator varies between Oracle versions.


Most of the GeoDjango functionality works with Locator features - I 
don't recall but I think there was a ticket about features only in 
Spatial and those would be Documented.


Oracle tests are slow for some reason and personally I don't think I've 
run full suite of spatial tests on it ever. (Though I just use 
GeoDjango, not develop it actively)



I think in the long run the requirement for any DB backend to stay in
core must be that we have a way to run tests automatically on that
backend. When working with the ORM, running tests on all backends
manually is impossible, as it takes just too much time. Especially if
you add Py3 to the mix. Currently Oracle - both gis and standard - is
missing automatic testing, and spatialite is missing too. Anybody have
the know-how to set these up? Any chance of getting another machine
with Oracle installation?


Setting automated tests shouldn't be a problem - I think problem is that 
to actually to be able to test you would need real Oracle server - and 
that costs money.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: supported backends in core

[Jani Tiainen]

29.5.2012 12:24, Anssi Kääriäinen kirjoitti:

On May 29, 10:50 am, Jani Tiainen  wrote:

28.5.2012 15:35, Anssi K ri inen kirjoitti:


On May 28, 3:14 pm, Chris Northwoodwrote:

I believe PostGIS 2.0 isn't supported 
yet:https://code.djangoproject.com/ticket/16455



I added some comments to that ticket.



I am going to hijack this thread, and ask what is the status of Oracle
and spatialite support? Anybody running tests on these backends?
spatialite seems a bit hard to install, and Oracle GIS functionality
seems to be available only in the commercial versions.


Oracle has two different GIS functionalities Locator and Spatial.
Locator is available for free and is subset of Spatial functionality.

Stupid thing is that you get full Spatial installed and you just have to
know which feature belongs to what version. Top of that features
included in Locator varies between Oracle versions.

Most of the GeoDjango functionality works with Locator features - I
don't recall but I think there was a ticket about features only in
Spatial and those would be Documented.

Oracle tests are slow for some reason and personally I don't think I've
run full suite of spatial tests on it ever. (Though I just use
GeoDjango, not develop it actively)


OK. I see Locator is in XE. Does the above mean that if I run gis test
on XE and those happen to use features from Spatial, then I am in
breach of their license? If so, I will not touch Oracle GIS
functionality.


Well you can't run GeoDjango on XE. Problem is that GeoDjango uses 
to/from WKT utility methods/functions and those don't work without 
database Java engine - and that does only exists in Oracle Standard 
edition and upwards.


And yes, if you use features from Spatial without proper license you (at 
least at some point ) breach it.


But since I'm not a lawyer I'm not sure what following clause will 
cover: "All software downloads are free, and most come with a Developer 
License that allows you to use full versions of the products at no 
charge while developing and prototyping your applications, or for 
strictly self-educational purposes."


Excerpt from Developer License [1]:

"LICENSE RIGHTS
We grant you a nonexclusive, nontransferable limited license to use the 
programs only for the purpose of developing, testing, prototyping and 
demonstrating your application, and not for any other purpose. If you 
use the application you develop under this license for any internal data 
processing or for any commercial or production purposes, or you want to 
use the programs for any purpose other than as permitted under this 
agreement, you must obtain a production release version of the program 
by contacting us or an Oracle reseller to obtain the appropriate 
license. You acknowledge that we may not produce a production release 
version of the program and any development efforts undertaken by you are 
at your own risk. We may audit your use of the programs. Program 
documentation, if available, may accessed online at "


Maybe someone should ask from Oracle support about legal advice.


I think in the long run the requirement for any DB backend to stay in
core must be that we have a way to run tests automatically on that
backend. When working with the ORM, running tests on all backends
manually is impossible, as it takes just too much time. Especially if
you add Py3 to the mix. Currently Oracle - both gis and standard - is
missing automatic testing, and spatialite is missing too. Anybody have
the know-how to set these up? Any chance of getting another machine
with Oracle installation?


Setting automated tests shouldn't be a problem - I think problem is that
to actually to be able to test you would need real Oracle server - and
that costs money.


I am running tests on XE on my local machine. We once had XE available
in automatic testing, too, but the installation somehow corrupted and
we don't have that anymore. The experience has been that XE is
somewhat picky about its installation environment, and once something
goes wrong it is very hard to fix. As far as I know Oracle XE
installation is all we need, and is free for our use case, but we
don't have even that.


From my experience *nix installations (except RHEL/Centos 
distributions) of Oracle (XE) is quite painful, but Windows 
installations goes pretty much without a pain.



  - Anssi




[1] http://www.oracle.com/technetwork/licenses/standard-license-152015.html

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Schema Alteration - Review needed!

[Jani Tiainen]

18.9.2012 1:59, Andrew Godwin kirjoitti:

Hi all,


There's doubtless some polishing and bugfixing that will be needed
before final release, but I'll be keeping on top of that (by developing
an app that uses it, partially) and making sure that 1.5 ships with
something that's decently solid, and with an Oracle backend if I can get
it working on my machine.


I can help with Oracle problems if you encounter a such thing since 
that's my main backend I work with. (And I have to deal with all the 
pain it causes)



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



--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Improved ajax support idea

[Jani Tiainen]

On Sat, Nov 24, 2012 at 7:10 PM, James Pic  wrote:

> Hello everybody,
>
> Thank you for your feedback. And pretty soon I will tackle this problem in
> an external app - or consider joining the party if somebody else has
> started, in this case feel free to let me know.
>
> I can understand most of the points made here, expect just one, please
> bare with me. Several hackers on this list stated that it has "obviously
> not its place in Django". I don't understand why generic non ajax views
> would have a their place in django, and ootb ajax support would not. But
> I'm really curious.
>
> It would be great if someone could elaborate on that, because from what I
> understand:
>
> - django has generic views, you are free to use them, you can use your
> own, or you can use those that are provided by external apps,
> - if django had generic views with ajax support, you would be free to use
> the ajax support, or use your own, or use those that are provided by
> external apps.
>
> I just fail to see the difference, it would be great if someone could
> explain that !
>
>
It's because generic views produces HTML that is pretty much standard
across the different browsers. There is no magic involved there. But there
is no standard that what ajax response should look like. Or actually that
acronym includes word XML.

For JS most of us does use some JS framework like jQuery, Dojo toolkit,
Mootools, ExtJS, just few to name. All of those like to have slightly
different responses. See the pattern?

There exists also few nice additional frameworks like Tastypie or Rest
framework that does excellent job to bring powerful tools that can talk
restful services - and those are quite suitable for ajax consumption. Some
of the frameworks even does have somekind of implementation to use them
directly.

-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

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

Re: Oracle testing issue, looks like bug: Separate connections to same DB

[Jani Tiainen]

27.12.2012 13:08, Shai Berger kirjoitti:

Hi all,

I'm seeing a problem with testing on Oracle, in a setting where there are two
defined databases that reference the same connection parameters (this is done
to enable operations in two parallel, separate transactions); the 'other'
database is not treated as a test database. This means that, during tests,
operations on it are performed on the 'production' database (this is all in a
development environment, thankfully).

Has anyone else run into this?

Django==1.4.3

Thanks,
Shai.



I assume that you're referring to test setup instructions on 
https://code.djangoproject.com/wiki/OracleTestSetup page?


You should see that there is defined TEST_USER, TEST_TBLSPACE and 
TEST_TBLSPACE_TMP variables to different names since those are ones used 
when running tests.


Django uses main user just to connect database and to create test users. 
Main user needs enough permissions (I've usually set that to DBA to make 
life easier) to enable creation of test user and needed tablespaces.


You can though have two different users there and even two different 
database instances if you do have those. Then there is no need to 
provide those custom values.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Oracle testing issue, looks like bug: Separate connections to same DB

[Jani Tiainen]

27.12.2012 14:41, Shai Berger kirjoitti:

Hi Jani and all,

On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote:

27.12.2012 13:08, Shai Berger kirjoitti:

Hi all,

I'm seeing a problem with testing on Oracle, in a setting where there are
two defined databases that reference the same connection parameters
(this is done to enable operations in two parallel, separate
transactions); the 'other' database is not treated as a test database.
This means that, during tests, operations on it are performed on the
'production' database (this is all in a development environment,
thankfully).

Has anyone else run into this?

Django==1.4.3

Thanks,

Shai.


I assume that you're referring to test setup instructions on
https://code.djangoproject.com/wiki/OracleTestSetup page?



Yes and no: I am referring to a variation on this theme.


You should see that there is defined TEST_USER, TEST_TBLSPACE and
TEST_TBLSPACE_TMP variables to different names since those are ones used
when running tests.



In my case, these values *should* be equal. I am not trying to run the Django
test suite, but tests for my own applications, and my applications rely on
having two separate connections to the same database.


Django uses main user just to [...]


I understand pretty well how the django test framework uses its connections.
I'm pointing out a case where it isn't doing it correctly.

To clarify: I am defining my databases by something like this in settings:

DATABASES = {
   'defailt' : ... # some full definition
}

DATABASES['auditlog'] = DATABASES['default'].copy()

and I even add this, which should help

DATABASES['auditlog']['TEST_MIRROR'] = 'default'

but when I run the tests, and print out the configuration from the test runner,
it looks like this:

{'DATABASES': {'auditlog': {'ENGINE': 'healarium.utils.oracle_backend',
 'HOST': 'oracle',
 'NAME': 'orcl',
 'OPTIONS': {'threaded': True},
 'PASSWORD': '',
 'PORT': '1521',
 'TEST_CHARSET': None,
 'TEST_COLLATION': None,
 'TEST_MIRROR': 'default',
 'TEST_NAME': None,
 'TEST_USER': 'test_usr1',
 'TIME_ZONE': 'Asia/Jerusalem',
 'USER': 'usr1'},
'default': {'ENGINE': 'healarium.utils.oracle_backend',
'HOST': 'oracle',
'NAME': 'orcl',
'OPTIONS': {'threaded': True},
'PASSWORD': 'Im_a_lumberjack',
'PORT': '1521',
'SAVED_PASSWORD': '',
'SAVED_USER': 'usr1',
'TEST_CHARSET': None,
'TEST_COLLATION': None,
'TEST_MIRROR': None,
'TEST_NAME': None,
'TEST_USER': 'test_usr1',
'TIME_ZONE': 'Asia/Jerusalem',
'USER': 'test_usr1'},

The thing to notice is how in 'default' there is a 'SAVED_PASSWORD' and
'SAVED_USER', and the 'USER' is equal to the 'TEST_USER', while in 'auditlog'
(the 'other' database connection) these do not hold (the only reason
'auditlog' has a correct 'TEST_USER' entry is that in trying to track this
down, I defined it explicitly for 'default' and it was copied).

Hope the issue is now clearer,


TEST_MIRROR = 'default'  means that instead of creating test database of 
"auditlog" using independent database connection Django will reuse 
connection to "default". That's how Django makes testing of replication 
happen (that's what TEST_MIRROR setting is for).


IOW it doesn't matter what your auditlog contains if you have 
TEST_MIRROR set. Django will reuse connection there.


You might get what you want by removing TEST_MIRROR option and setting 
TEST_CREATE and TEST_USER_CREATE values as false. And propably defining 
that auditlog database test depends on default test database.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Oracle testing issue, looks like bug: Separate connections to same DB

[Jani Tiainen]

27.12.2012 14:41, Shai Berger kirjoitti:

Hi Jani and all,

On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote:

27.12.2012 13:08, Shai Berger kirjoitti:

Hi all,

I'm seeing a problem with testing on Oracle, in a setting where there are
two defined databases that reference the same connection parameters
(this is done to enable operations in two parallel, separate
transactions); the 'other' database is not treated as a test database.
This means that, during tests, operations on it are performed on the
'production' database (this is all in a development environment,
thankfully).

Has anyone else run into this?

Django==1.4.3

Thanks,

Shai.


I assume that you're referring to test setup instructions on
https://code.djangoproject.com/wiki/OracleTestSetup page?



Yes and no: I am referring to a variation on this theme.


You should see that there is defined TEST_USER, TEST_TBLSPACE and
TEST_TBLSPACE_TMP variables to different names since those are ones used
when running tests.



In my case, these values *should* be equal. I am not trying to run the Django
test suite, but tests for my own applications, and my applications rely on
having two separate connections to the same database.



Just out of curiosity - what's the rationale to duplicate connection 
information? Why it's so important?


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Oracle testing issue, looks like bug: Separate connections to same DB

[Jani Tiainen]

27.12.2012 15:28, Shai Berger kirjoitti:

On Thursday 27 December 2012 15:11:31 Jani Tiainen wrote:


TEST_MIRROR = 'default'  means that instead of creating test database of
"auditlog" using independent database connection Django will reuse
connection to "default". That's how Django makes testing of replication
happen (that's what TEST_MIRROR setting is for).



Removing TEST_MIRROR changes nothing (except the printing of databases). If
you were correct, and TEST_MIRROR were the issue, then this would cause the
whole test suite to fail on attempt to create the 'auditlog' test database
(which would already exist); but no attempt is made to create this database.

Also, my tests currently fail because they include some
'model.objects.get(...)' call, which would succeed if the test were run on an
empty database; instead, it fails because it retrieves more than one record.
The number of records returned increases each time I run the test, proving (to
me, at least) that the records are written to a persistent database, not one
that is deleted when the tests end.



It might be very much that such a setup you're looking is not possible 
for testing.


Though still it doesn't make any sense to duplicate connections to same 
database, to same user.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Oracle testing issue, looks like bug: Separate connections to same DB

[Jani Tiainen]

27.12.2012 15:32, Shai Berger kirjoitti:

On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote:


Just out of curiosity - what's the rationale to duplicate connection
information? Why it's so important?


As I noted before, the idea is to use the second connection to write things in
a separate transaction. As the name 'auditlog' implies, this is an audit log;
I don't want records written there to be rolled back when a request encounters
an error (one of these records may well include the exception).



I've never done such a setup (we always have separate schemas) so I've 
feeling that testing such a setup doesn't work right away.


One option could be create separate test users and add synonyms (by 
custom SQL script on auditlog test database creation) for auditlog user 
to default test user auditlog tables.


There also exists a oldish ticket: 
https://code.djangoproject.com/ticket/14415


That indicates that issue is fixed...

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Oracle testing bug (was Re: Oracle testing issue, looks like bug: Separate connections to same DB)

[Jani Tiainen]

31.12.2012 14:18, Shai Berger kirjoitti:

On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote:


Seems like you are correct [...]. Please open a bug.


For anyone interested that isn't on the new-bugs list, it's
https://code.djangoproject.com/ticket/19542

For anyone else: my apologies for the noise.

Shai.



Can you please setup simple testcase to ease bugfixing?

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Reminder: pending Oracle fixes and issues

[Jani Tiainen]

17.1.2013 15:50, Shai Berger kirjoitti:

Hi Django devs, and in particular Oracle users,

This is to remind you of fixes I proposed for the Oracle backend, which were
mostly discussed and accepted, but seem not to have made it into the codebase
yet. I am referring to:



What comes to your fix for named parameters I would give it +0. Not 
necessity but I would found it useful, specially when adding lot of 
parameters like we have to do in few places to use our legacy data.


Continuing to Oracle fixes I would also like to see incorporated fix for 
bug #19606 [2] for unicode support and Django detection algorithm due 
changes between cx_Oracle versions 5.0.x and 5.1.x. PR #650 [1] exists 
for that.



[1] https://github.com/django/django/pull/650
[2] https://code.djangoproject.com/ticket/19606

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Test failures under Oracle

[Jani Tiainen]

10.3.2013 23:03, Petite Abeille kirjoitti:


On Mar 10, 2013, at 9:36 PM, Ian Kelly  wrote:


These particular lookups have a long history of being tweaked due to
users coming up with installations where the existing queries did not
work.  See tickets #5985, #11017 and #14149.  I'd rather not reopen
this issue unless the current implementation can documentably be shown
to be broken.


Fair enough…

Another point perhaps worthwhile mentioning:

 # There's no way for the DatabaseOperations class to know the
 # currently active Oracle version, so we do some setups here.

https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L574

That information can be extracted from v$version, v$instance, 
dbms_db_version.version, product_component_version, etc, etc. The choice is 
yours.



Well since we're using Oracle in production and even we dared to venture 
in GeoDjango parts we've some expertise to share.


To my knowledge there isn't any installations that does have cx_Oracle 
as prepackaged version, and considering that even 5.0 version dropped 
support for Oracle 8i. cx_Oracle 5.0 was released on December 2008.


Latest major version 5.1.0 was released on March 19th, 2011 (which is 
about two years already) and latest 5.1.2 was released on July 6th, 2012.


Django docs state 4.3.1 as required - considering it's been released i 
2007. I think it wouldn't hurt anyone to pump required version up to 
5.1+ since that's the first version uncode ready and should support 
python 3.3 as well.


Django itself drops quite fast security updates - Oracle does it a bit 
longer, though it doesn't hang on older databases too long either.


Oracle 9.2 support ended July 2007 (extended 2010)
Oracle 10.1 support ended January 2009 (extended 2012)
Oracle 10.2 support ended July 2010 (extended 2013)
Oracle 11.1 supports ended August 2012 (extended 2015)
Oracle 11.2 support ends January 2015 (extended 2018)

So yes, people do use older version, though considering that any 
sensible organisation has updated to newer supported versions as time 
passes. Considering that Oracle is really marginal backend for Django 
comparing to others I think it's reasonable to drop support older ones, 
like 9.2 and 10.1.


Another nasty issue is that along the road license coverage has changed: 
Oracle 9i, 10g and 11g does have differet set of spatial operators 
included with Locator (free part with Standard and EE versions) and 
Oracle Spatial (separately licensed with EE version of Oracle).


Now here comes the fun: All installations do have all spatial operations 
as well. Only way to distinguish them is to consult Oracle 
Locator/Spatial reference guide.


This is very bitchy thing with GeoDjango since you can easily go and 
accidentally use something that you're not licensed for.


What comes to other issues - I'm not upset if Oracle backend fails 
tests, since I don't expect it even to do pass all because "it's Oracle".


What comes to magic knowledge of Oracle, that I do have and I can share 
it - but someone has to ask it first.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

--
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: Support for 3D Oracle Spatial Geometries

[Jani Tiainen]

Hi,

We ran exactly same situation and we actually wrote did a slightly different 
solution - we now do have (yet to be opensourced) a backend that actually reads 
SDO_GEOMETRY directly and writes a string that resembles SDO_GEOMETRY and is 
parsed to real SDO_GEOMETRY with small PL/SQL package utility function.

Advantages for that approach is that it's fastest solution so far (Apparently 
Oracle context switch between pl/sql and java is dead slow) and it works even 
on Oracle XE versions. Downside is of course requirement to install one time 
pl/sql package.

Now there are few caveats depending on version of Oracle you use. Oracle does 
return a faulty geometries some times, specially for extents, those may (or may 
not) pass as GML.

-- 

Jani Tiainen

On Mon, 3 Nov 2014 16:37:04 +1100
Michael Sexton  wrote:

> Hi
> 
> I have recently started using Django and tried to use it with our legacy 
> Oracle Spatial database. The geometries we store in Oracle are all 3D and as 
> such don’t work with Django. It boils down to this:
> 
> select sdo_util.to_wktgeometry(sdo_geometry(3001, null, 
> SDO_POINT_TYPE(120,-30, 0), null, null))  from dual;
> 
> Yielding the following error:
> 
> ORA-13199: 3D geometries are not supported by geometry WKB/WKT generation.
> ORA-06512: at "MDSYS.MD", line 1723
> ORA-06512: at "MDSYS.MDERR", line 17
> ORA-06512: at "MDSYS.SDO_UTIL", line 2509
> 
> However, as I discovered, all is not lost. A similar query:
> 
> select sdo_util.to_gmlgeometry(sdo_geometry(3001, null, 
> SDO_POINT_TYPE(120,-30, 0), null, null))  from dual;
> 
> Delivers something we can work with:
> 
> http://www.opengis.net/gml 
> <http://www.opengis.net/gml>">120.0,-30.0,0.0 
> 
> I am new to Python and Django, so I looked through the code, forked the 
> Django project, and made five changes:
> 
> Call to Oracle uses SDO_UTIL.TO_GMLGEOMETRY to output GML:
> https://github.com/comtesacristain/django/commit/4a5732d3069fc648b887c7c7000e99f45fe60d56
>  
> <https://github.com/comtesacristain/django/commit/4a5732d3069fc648b887c7c7000e99f45fe60d56>
> 
> GML regex (this probably needs work as I am terrible at regexes):
> https://github.com/comtesacristain/django/commit/96d06f8392432121610a07ed8d7a1fc4c7f5aa8c
>  
> <https://github.com/comtesacristain/django/commit/96d06f8392432121610a07ed8d7a1fc4c7f5aa8c>
> 
> Accessed part of the GDAL C libraries to read from GML:
> https://github.com/comtesacristain/django/commit/3cefe8651a8df60bbade66ec0410c67ee2bde1d9
>  
> <https://github.com/comtesacristain/django/commit/3cefe8651a8df60bbade66ec0410c67ee2bde1d9>
> 
> Checked against the GML regex and used GDAL module
> https://github.com/comtesacristain/django/commit/2eaad60782f2d72836b026bd2cca0d9a1cfff541
>  
> <https://github.com/comtesacristain/django/commit/2eaad60782f2d72836b026bd2cca0d9a1cfff541>
> 
> Part of GDAL module which makes the call to the GDAL C API
> https://github.com/comtesacristain/django/commit/ad5808a5b4b0b7e6b1efb4d29dc09e7d15a344b7
>  
> <https://github.com/comtesacristain/django/commit/ad5808a5b4b0b7e6b1efb4d29dc09e7d15a344b7>
> 
> I was wondering what it would take to have these made part of the Django 
> project? I am not the greatest coder, but I thought these might help with 
> what is currently a bug in the use of Django for 3D spatial geometries in 
> Oracle.
> 
> Best Regards
> 
> Michael Sexton.
> 
> 
> 
> 
> -- 
> 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/A82D27CC-DA81-49B7-9933-040C88821BC9%40gmail.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/20141104084933.5ce407c8%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with Oracle GIS backend

[Jani Tiainen]

Hi,

We're still running Oracle and GIS. Though we do have built custom
backend based on Django GIS backend - mainly to have support for
Oracle XE, 3D functionality and in general to make it faster.

It's currently closed source but we're working on to open source it
in hope that it could interest more wider audience (mainly because it
would enable GIS use with free Oracle XE).

On Tue, 24 Mar 2015 04:48:38 -0700 (PDT)
Tim Graham  wrote:

> I also advertised this on the geodjango mailing list with the following 
> message <https://groups.google.com/d/topic/geodjango/D_nL5W4vxmE/discussion>
> :
> 
> Do we have any users of the Oracle GIS backend that have interest and 
> ability to help maintain it? Claude has worked on several issues for 1.9 
> that need to be completed on Oracle. If we cannot find help, then I think 
> we'll be forced to declare the Oracle GIS backend unmaintained and drop 
> support for it.
> 
> issues:
> * https://code.djangoproject.com/ticket/12400#comment:12
> * https://github.com/django/django/pull/4027
> 
> On Monday, March 16, 2015 at 3:20:40 PM UTC-4, Claude Paroz wrote:
> >
> > Hi,
> >
> > In ticket #24214, I built a patch to replace all geo-specific Manager 
> > methods by class-based ORM functions. This will allow us to get rid of 
> > convoluted query code in the GeoDjango ORM. It will also be far much easier 
> > to add support for specific database functions. The code is already in good 
> > shape, however we are missing the Oracle part of the patch. I won't work on 
> > that part myself, that's why I'm here to ask for help with it from anyone 
> > which is a bit familiar with the Oracle GIS backend. Help much appreciated!
> >
> > https://code.djangoproject.com/ticket/24214
> >
> > Claude
> >
> 
> -- 
> 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/9a43a6d2-eec9-4518-afc3-0d3d0b4e5bef%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Jani Tiainen

-- 
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/20150325095800.78250f8d%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with Oracle GIS backend

[Jani Tiainen]

On Thu, 26 Mar 2015 22:29:00 +0200
Shai Berger  wrote:

> Hi Jani.
> 
> On Wednesday 25 March 2015 09:58:00 Jani Tiainen wrote:
> > 
> > We're still running Oracle and GIS. Though we do have built custom
> > backend based on Django GIS backend - mainly to have support for
> > Oracle XE, 3D functionality and in general to make it faster.
> > 
> > It's currently closed source but we're working on to open source it
> > in hope that it could interest more wider audience (mainly because it
> > would enable GIS use with free Oracle XE).
> > 
> That is good news. I would like to draw your attention to 
> https://code.djangoproject.com/ticket/21273 where a partial attempt was 
> already made to add GIS/Oracle-XE support.
> 
> Thanks,
>   Shai.

Well, last comment is mine :)  describing exactly how our backend does work in 
general level and explains rationales why we chose a slightly different 
approach.


-- 
Jani Tiainen

-- 
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/20150330163219.4b0fe487%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Inheritance in admin classes

[Jani Tiainen]

Hi,

I had my fun when I tried to add more inline stuff to a Admin form, and I ended 
up doing thiskind of stuff:

https://janimagik.wordpress.com/2015/05/05/django-admin-and-inline-chaining/

I guess problem is how Django admin uses metaclass to do some magic behind the 
scenes.

On Thu, 2 Jul 2015 03:30:59 -0700 (PDT)
kny...@knyg.ht wrote:

> I think it could be - if not the exact same issue - one that would be fixed 
> by the same patch. My specific use case is something like this:
> 
> class MyUserAdmin(UserAdmin):
> def get_fieldsets(self, request, obj=None):
> fieldsets = super().get_fieldsets(request, obj)
> fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields'])
> fieldsets[0][1]['fields'].append('category')
> 
> which is already pretty ugly, but needs uglifying further:
> 
> class MyUserAdmin(UserAdmin):
> def get_fieldsets(self, request, obj=None):
> fieldsets = super().get_fieldsets(request, obj)
> fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields'])
> 
> if 'category' not in fieldsets[0][1]['fields'][-1]:
> fieldsets[0][1]['fields'].append('category')
> 
> Logically, they could be the same issue, but I haven't dug in to see if 
> this is the case. Is it really the case that the overhead of deepcopy() is 
> too much here?
> 
> 
> On Thursday, July 2, 2015 at 2:33:24 AM UTC+1, Tim Graham wrote:
> >
> > Could it be https://code.djangoproject.com/ticket/22828 ?
> >
> > On Wednesday, July 1, 2015 at 5:32:48 PM UTC-4, kny...@knyg.ht wrote:
> >>
> >> Hello all,
> >>
> >> So, I was talking to kezabelle on IRC some months back about a problem I 
> >> was having, and finally remembered to post something.
> >>
> >> If I inherit from an admin class, and override something like 
> >> get_fields(), I was getting back duplicates of fields if I used super() to 
> >> get the existing fields and add to them. And if I reload the page, I would 
> >> get more and more fields until I restarted the dev server. Something about 
> >> ModelAdmin being one instance per process. It seems very counter-intuitive 
> >> to me, and I was wondering if anyone was considering fixing this? I'm 
> >> under 
> >> the impression it might be some work to do.
> >>
> >> Cheers,
> >> Tom
> >>
> >
> 
> -- 
> 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/bd375dce-428f-4ca3-a2bc-2533f47134db%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Jani Tiainen

-- 
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/20150702134617.515b79d7%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

Re: draft blog post for Oracle help

[Jani Tiainen]

Hi all,

I'm volunteering myself to maintain both Oracle and Oracle GIS backends.

I've been developing applications based on Oracle for almost 20 years now and 
I've been maintaining Oracle installations and databases.

I've been developing with Django and it's GIS parts with almost 10 years now. 
I've previously contributed few very trivial patches and I've regulary keep 
answering questions on #django and hanging around in #django-dev with nick 
"jtiai".


On Thu, 13 Aug 2015 09:12:17 -0700 (PDT)
Tim Graham  wrote:

> I've drafted a blog post to advertise our need for Oracle expertise. Please 
> take a look and give feedback before it's published. Thanks!
> 
> Django team seeks help maintaining Oracle and Oracle GIS backends
> ---
> 
> Several members of the Django team that have previously provided Oracle
> expertise no longer work with Oracle in their day jobs, and therefore, the 
> team
> is seeking new contributors who have an ongoing interest in the backend.
> 
> Ideally, the team seeks to move the Oracle backend from "built-in" status, 
> to a pip
> installable backend that would be maintained under the "django" GitHub 
> account.
> Your duties would include monitoring a build that runs with Django master 
> and the
> latest version of the Oracle backend and fixing any issues that arise. To 
> help with
> the continuous integration infrastructure, knowledge of maintaining Oracle 
> servers
> would also be a plus, but these duties could be split among several people. 
> Please
> introduce yourself on the `django-developers mailing list`_ if this is 
> something you
> are interested in.
> 
> Also, the Oracle GIS backend has been broken for several months and
> no one has answered `requests for help`_ on the django-developers and
> geodjango mailing lists. If no one helps out, this backend will be dropped 
> in
> Django 1.9. This is the least used backend according to the `Django 
> Developers
> Community Survey`_, receiving 5 votes out of more than 3,000 responses.
> 
> .. _django-developers mailing list: 
> https://groups.google.com/forum/#!forum/django-developers
> .. _requests for help: 
> https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
> .. _Django Developers Community Survey: 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics
> 
> -- 
> 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/68c78921-001d-4171-bdd7-541f048734bc%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Jani Tiainen

-- 
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/20150819093553.7aafd4c6%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

Re: draft blog post for Oracle help

[Jani Tiainen]

All hands on deck.. ;)

I wouldn't mind having an additional pair of hands to help. Normal 
backend is in rather good shape - all tests do pass. GIS backend on the 
other hand is having more or less fun-to-fix issues.


I've made some progress to make current backend even pass the tests. If 
you want to help, you can poke me on #django or #django-dev irc channels 
so I can give you a sitrep what I know and what needs further 
investigations.


On 07.09.2015 20:49, Mariusz Felisiak wrote:

Hi everybody,

I would like to volunteer to help maintain Oracle and Oracle GIS 
backend. I have been developing (commercial) apps with Django 
framework and oracle backend for 8 years now. I am familiar with the 
problems associated with it because few times I have been forced to 
find ways to solve them:)


FeliXX

W dniu czwartek, 13 sierpnia 2015 18:12:17 UTC+2 użytkownik Tim Graham 
napisał:


I've drafted a blog post to advertise our need for Oracle
expertise. Please take a look and give feedback before it's
published. Thanks!

Django team seeks help maintaining Oracle and Oracle GIS backends

---

Several members of the Django team that have previously provided
Oracle
expertise no longer work with Oracle in their day jobs, and
therefore, the team
is seeking new contributors who have an ongoing interest in the
backend.

Ideally, the team seeks to move the Oracle backend from "built-in"
status, to a pip
installable backend that would be maintained under the "django"
GitHub account.
Your duties would include monitoring a build that runs with Django
master and the
latest version of the Oracle backend and fixing any issues that
arise. To help with
the continuous integration infrastructure, knowledge of
maintaining Oracle servers
would also be a plus, but these duties could be split among
several people. Please
introduce yourself on the `django-developers mailing list`_ if
this is something you
are interested in.

Also, the Oracle GIS backend has been broken for several months and
no one has answered `requests for help`_ on the django-developers and
geodjango mailing lists. If no one helps out, this backend will be
dropped in
Django 1.9. This is the least used backend according to the
`Django Developers
Community Survey`_, receiving 5 votes out of more than 3,000
responses.

.. _django-developers mailing list:
https://groups.google.com/forum/#!forum/django-developers
<https://groups.google.com/forum/#%21forum/django-developers>
.. _requests for help:
https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
<https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion>
.. _Django Developers Community Survey:

https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics

<https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics>

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/bbb2ccfe-cc2b-4665-b440-6f211d2f8808%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/bbb2ccfe-cc2b-4665-b440-6f211d2f8808%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

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

Re: draft blog post for Oracle help

[Jani Tiainen]

On 08.09.2015 14:08, Jani Tiainen wrote:

All hands on deck.. ;)

I wouldn't mind having an additional pair of hands to help. Normal 
backend is in rather good shape - all tests do pass. GIS backend on 
the other hand is having more or less fun-to-fix issues.


I've made some progress to make current backend even pass the tests. 
If you want to help, you can poke me on #django or #django-dev irc 
channels so I can give you a sitrep what I know and what needs further 
investigations.




Hit enter too fast. I forgot to mention that my IRC nick is jtiai :-)


On 07.09.2015 20:49, Mariusz Felisiak wrote:

Hi everybody,

I would like to volunteer to help maintain Oracle and Oracle GIS 
backend. I have been developing (commercial) apps with Django 
framework and oracle backend for 8 years now. I am familiar with the 
problems associated with it because few times I have been forced to 
find ways to solve them:)


FeliXX

W dniu czwartek, 13 sierpnia 2015 18:12:17 UTC+2 użytkownik Tim 
Graham napisał:


I've drafted a blog post to advertise our need for Oracle
expertise. Please take a look and give feedback before it's
published. Thanks!

Django team seeks help maintaining Oracle and Oracle GIS backends

---

Several members of the Django team that have previously provided
Oracle
expertise no longer work with Oracle in their day jobs, and
therefore, the team
is seeking new contributors who have an ongoing interest in the
backend.

Ideally, the team seeks to move the Oracle backend from
"built-in" status, to a pip
installable backend that would be maintained under the "django"
GitHub account.
Your duties would include monitoring a build that runs with
Django master and the
latest version of the Oracle backend and fixing any issues that
arise. To help with
the continuous integration infrastructure, knowledge of
maintaining Oracle servers
would also be a plus, but these duties could be split among
several people. Please
introduce yourself on the `django-developers mailing list`_ if
this is something you
are interested in.

Also, the Oracle GIS backend has been broken for several months and
no one has answered `requests for help`_ on the django-developers and
geodjango mailing lists. If no one helps out, this backend will
be dropped in
Django 1.9. This is the least used backend according to the
`Django Developers
Community Survey`_, receiving 5 votes out of more than 3,000
responses.

.. _django-developers mailing list:
https://groups.google.com/forum/#!forum/django-developers
.. _requests for help:
https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
<https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion>
.. _Django Developers Community Survey:

https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/bbb2ccfe-cc2b-4665-b440-6f211d2f8808%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen


--
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/55EEC201.9000904%40gmail.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

[Jani Tiainen]

On 05.11.2015 09:54, José Tomás Tocino García wrote:


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?


Well first, inspectdb does only processes tables. As I understood your 
case involves views which are not traversed by Django.


Secondly, how often inspectdb is required to run with just a subset? 
Tim' suggestion is quite nice (wildcarded query).


Then we hit edge cases, since Django models by default are read/write 
how should select-only tables (or views if such behavior is implemented) 
should be handled? Should there be overridden methods that tries to 
disable invalid actions?


Now we hit another thing. If you do have spatial fields your schema will 
get temporary spatial objects, MDRT_*. Then usecase would be getting all 
other except those MDRT_* tables (or maybe exclude all tables having *$*)





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.


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

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

[Jani Tiainen]

Heres a link how to fetch data about priviledges and such:

http://docs.oracle.com/cd/B19306_01/network.102/b14266/admusers.htm#i1008437


On 05.11.2015 10:28, Jani Tiainen wrote:



On 05.11.2015 09:54, José Tomás Tocino García wrote:


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?


Well first, inspectdb does only processes tables. As I understood your 
case involves views which are not traversed by Django.


Secondly, how often inspectdb is required to run with just a subset? 
Tim' suggestion is quite nice (wildcarded query).


Then we hit edge cases, since Django models by default are read/write 
how should select-only tables (or views if such behavior is 
implemented) should be handled? Should there be overridden methods 
that tries to disable invalid actions?


Now we hit another thing. If you do have spatial fields your schema 
will get temporary spatial objects, MDRT_*. Then usecase would be 
getting all other except those MDRT_* tables (or maybe exclude all 
tables having *$*)





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
<mailto:django-developers%2bunsubscr...@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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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.




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

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

[Jani Tiainen]

Maybe that view thing as been changed along the years.

My proposal would be allow two switches, inclusion and exclusion with a
wildcard. Where exclusion would override any inclusion.

I guess that would satisfy most of the use cases. How that sounds?

On Thu, Nov 5, 2015 at 3:59 PM, José Tomás Tocino García  wrote:

>
>> Well first, inspectdb does only processes tables. As I understood your
>> case involves views which are not traversed by Django.
>>
>
> Are you sure about that? inspectdb
> calls connection.introspection.table_names(cursor) that, in the case of
> Oracle, calls oracle.introspection.DatabaseIntrospection.get_table_list
> which queries BOTH tables AND views:
>
> """
> Returns a list of table and view names in the current database.
> """
> cursor.execute("SELECT TABLE_NAME, 't' FROM USER_TABLES UNION ALL "
>"SELECT VIEW_NAME, 'v' FROM USER_VIEWS")
>
> At the end of the day, views are pretty similar at the query level.
>
>
>> Secondly, how often inspectdb is required to run with just a subset? Tim'
>> suggestion is quite nice (wildcarded query).
>>
>
> Well, that depends on the case. As I already stated, I'm not against the
> wildcarded query.
>
>
>> Then we hit edge cases, since Django models by default are read/write how
>> should select-only tables (or views if such behavior is implemented) should
>> be handled? Should there be overridden methods that tries to disable
>> invalid actions?
>>
>
> I think that's up to the user to take care of, not Django.
>
>
>> Now we hit another thing. If you do have spatial fields your schema will
>> get temporary spatial objects, MDRT_*. Then usecase would be getting all
>> other except those MDRT_* tables (or maybe exclude all tables having *$*)
>>
>
> Again, I honestly fail to see what this has to do with my particular
> patch. I feel like this is getting out of hand.
>
>
> --
> 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/CAAOwDo7eG913Y_5Ch1iv7J1WeVU_7bGpft%3DNSsiqj-GB%3DTa2GA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAAOwDo7eG913Y_5Ch1iv7J1WeVU_7bGpft%3DNSsiqj-GB%3DTa2GA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

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

Oracle GIS update

[Jani Tiainen]

Hi, I finally had time to get back on Oracle GIS issues.

I ran test suite against 1.9.x and 7 tests fails.

3 tests are most probably due different algorithms used to calculate
geographical distance and areas. My proposal for fix is to use backend
spesific values.

Failing testcases are:
==
FAIL: test_distance_function
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 4899.67677194225 != 4891.2 within 2 places
==
FAIL: test_geography_area (gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
==
FAIL: test06_geography_area (gis_tests.geogapp.tests.GeographyTest)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
==



4 tests are unknown failures that require further investigation.
Failing testcases are:
==
FAIL: test_difference (gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_difference_mixed_srid
==
FAIL: test_intersection (gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_sym_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==

-- 
Jani Tiainen

-- 
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/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%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]

On 05.11.2015 15:59, José Tomás Tocino García wrote:





Well first, inspectdb does only processes tables. As I understood
your case involves views which are not traversed by Django.


Are you sure about that? inspectdb 
calls connection.introspection.table_names(cursor) that, in the case 
of Oracle, calls 
oracle.introspection.DatabaseIntrospection.get_table_list which 
queries BOTH tables AND views:


"""
Returns a list of table and view names in the current database.
"""
cursor.execute("SELECT TABLE_NAME, 't' FROM USER_TABLES UNION 
ALL "

   "SELECT VIEW_NAME, 'v' FROM USER_VIEWS")




Listing views as well is a relatively new feature (added to 1.8):
https://github.com/django/django/commit/b8cdc7dcc3fc6897fb2a75f90023f5c67aad327f

That was a bit surprise. Specially that functionality is really 
undocumented.


https://docs.djangoproject.com/en/1.8/ref/django-admin/#inspectdb

Documentatiuon states that it introspects tables, not views.

Documentation states that inspectdb works ith PostgreSQL, MySQL and 
SQLite. There is no mention of Oracle at all.


--

Jani Tiainen

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

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

[Jani Tiainen]

On 06.11.2015 10:54, José Tomás Tocino García wrote:


Maybe that view thing as been changed along the years.

My proposal would be allow two switches, inclusion and exclusion
with a wildcard. Where exclusion would override any inclusion.

I guess that would satisfy most of the use cases. How that sounds?


As I already stated before, filtering using wildcards is not going to 
make it for me, because in my case I don't get a list of available 
tables in the first place (because the current introspection mechanism 
doesn't return tables not owned by the user).




Well maybe extending queries to do that. Wonder is there similiar issues 
with postgresql?



--
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/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%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/563C820E.9060606%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing Django using Docker

[Jani Tiainen]

Hi,

I think you should document this in Wiki at least.

Few additional questions notes:

What's the Docker overhead? (starup/shutdown time)

Could waiting for db container be more robust? Now it's just "random 
number".


Using docker-compose would be nice to avoid problems with container 
startup times.



On 07.11.2015 14:46, Andreas Madsack wrote:

Hello,

I did a first version of a Dockerfile for testing using Docker with a 
Postgresql Docker container.

see https://github.com/mfa/django-runtests-docker

The readme contains a walkthrough for a fresh digitialocean box (you 
need 1GB RAM! 512MB and a swap file also works).

On a linux host you can run the testsuite with "sh run.sh".

Should this way of running the tests be integrated in the docs?
And should the Dockerfile and the runscript be in the django tests folder?

Regards,
Andreas
--
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/5f4750dd-36c6-4d80-b222-6d203ada2974%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/56405370.8060100%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle GIS update

[Jani Tiainen]

Well I fix those algorithm based errors, and do deeper analysis for 
those yet unknown ones. If I can't figure out why that happens I create 
ticket for each and mark them expected failures.


On 10.11.2015 21:23, Tim Graham wrote:
The changes to get it running were merged in September. Absent a 
proper solution for those 6 failures, I agree it would be a good idea 
to mark them expectedFailure so we can get the build running on CI 
before 1.9 final.


On Tuesday, November 10, 2015 at 1:54:42 PM UTC-5, Marc Tamlyn wrote:

Thanks for getting it running at all!

It looks to me like those tests just need to be less accurate for
Oracle, good plan.

Did you have any specific changes to make to get it to run at all?
If so we should include those soon, irrespective of whether the
fixes for these other tests make it into 1.9 final.

Marc

On 5 Nov 2015 8:21 pm, "Jani Tiainen" > wrote:

Hi, I finally had time to get back on Oracle GIS issues.

I ran test suite against 1.9.x and 7 tests fails.

3 tests are most probably due different algorithms used to
calculate geographical distance and areas. My proposal for fix
is to use backend spesific values.

Failing testcases are:
==
FAIL: test_distance_function
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 4899.67677194225 != 4891.2 within 2 places
==
FAIL: test_geography_area
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5
places
==
FAIL: test06_geography_area
(gis_tests.geogapp.tests.GeographyTest)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5
places
==



4 tests are unknown failures that require further investigation.
Failing testcases are:
==
FAIL: test_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_difference_mixed_srid
==
FAIL: test_intersection
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_sym_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==

    -- 
    Jani Tiainen



-- 
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-develop...@googlegroups.com
.
To post to this group, send email to
django-d...@googlegroups.com .
Visit this group at
http://groups.google.com/group/django-developers
<http://groups.google.com/group/django-developers>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.com

<https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/745995fb-a0c0-43f0-a5a4-2bdb8e46bc54%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/745995fb-a0c0-43f0-a5a4-2bdb8e46bc54%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 

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

[Jani Tiainen]

Hi,

I guess it's just about crafting proper SQL for Oracle to do proper 
introspection and do a PR to be inline with other backends what comes to 
table/view discovery.


On 11.11.2015 14:14, José Tomás Tocino wrote:

So... is this going anywhere?

El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
escribió:


Well maybe extending queries to do that. Wonder is there
similiar issues with postgresql?


Nope, I've just tried granting SELECT access to a user and he can
inspect the tables properly (in postgresql):

postgres=# CREATE DATABASE permissions;
CREATE DATABASE
postgres=# \c permissions;
You are now connected to database "permissions" as user
"postgres".
permissions=# create table foo (id int, name varchar(255));
CREATE TABLE
permissions=# GRANT CONNECT ON DATABASE permissions to tester;
GRANT
permissions=# GRANT USAGE ON SCHEMA public TO tester;
GRANT
permissions=# GRANT SELECT ON foo TO tester;
GRANT
permissions=# \q
(ENV)vagrant@vagrant-ubuntu-trusty-64:~$ ./manage.py inspectdb
# This is an auto-generated Django model module.
# You'll have to do the following manually to clean this up:
#   * Rearrange models' order
#   * Make sure each model has one field with primary_key=True
#   * Remove `managed = False` lines if you wish to allow
Django to create, modify, and delete the table
# Feel free to rename the models, but don't rename db_table
values or field names.
#
# Also note: You'll have to insert the output of 'django-admin
sqlcustom [app_label]'
# into your database.
from __future__ import unicode_literals

from django.db import models


class Foo(models.Model):
id = models.IntegerField(blank=True, null=True)
name = models.CharField(max_length=255, blank=True, null=True)

class Meta:
managed = False
db_table = 'foo'


So there's that


-- 
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-develop...@googlegroups.com.
To post to this group, send email to
django-d...@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/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%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/9acc3506-6585-4dd6-9463-0d431707e441%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/56433744.6010104%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle GIS update

[Jani Tiainen]

As noted by some of you managed to get it done.

Most problematic thing seems to be "Texas" geometry which causes 
problems in Oracle and sometimes with SpatiaLite as well.


I'll try to investigate if that data could be improved to create more 
consistent test results.


On 10.11.2015 21:23, Tim Graham wrote:
The changes to get it running were merged in September. Absent a 
proper solution for those 6 failures, I agree it would be a good idea 
to mark them expectedFailure so we can get the build running on CI 
before 1.9 final.


On Tuesday, November 10, 2015 at 1:54:42 PM UTC-5, Marc Tamlyn wrote:

Thanks for getting it running at all!

It looks to me like those tests just need to be less accurate for
Oracle, good plan.

Did you have any specific changes to make to get it to run at all?
If so we should include those soon, irrespective of whether the
fixes for these other tests make it into 1.9 final.

Marc

On 5 Nov 2015 8:21 pm, "Jani Tiainen" > wrote:

Hi, I finally had time to get back on Oracle GIS issues.

I ran test suite against 1.9.x and 7 tests fails.

3 tests are most probably due different algorithms used to
calculate geographical distance and areas. My proposal for fix
is to use backend spesific values.

Failing testcases are:
==
FAIL: test_distance_function
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 4899.67677194225 != 4891.2 within 2 places
==
FAIL: test_geography_area
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5
places
==
FAIL: test06_geography_area
(gis_tests.geogapp.tests.GeographyTest)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5
places
==



4 tests are unknown failures that require further investigation.
Failing testcases are:
==
FAIL: test_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_difference_mixed_srid
==
FAIL: test_intersection
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_sym_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==

-- 
Jani Tiainen



-- 
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-develop...@googlegroups.com
.
To post to this group, send email to
django-d...@googlegroups.com .
Visit this group at
http://groups.google.com/group/django-developers
<http://groups.google.com/group/django-developers>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.com

<https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/745995fb-a0c0-43f0-a5a4-2bdb8e46bc54%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/745995fb-a0c0-43f0-a5a4-2bdb8e46bc54%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/op

Re: Test optimizations (2-5x as fast)

[Jani Tiainen]

On Fri, 2011-05-13 at 16:57 -0700, Erik Rose wrote:
> tl;dr: I've written an alternative TestCase base class which makes 
> fixture-using tests much more I/O efficient on transactional DBs, and I'd 
> like to upstream it.
> 
> Greetings, all! This is my first django-dev post, so please be gentle. :-) I 
> hack on support.mozilla.com, a fairly large Django site with about 1000 
> tests. Those tests make heavy use of fixtures and, as a result, used to take 
> over 5 minutes to run. So, I spent a few days seeing if I could cut the 
> amount of DB I/O needed. Ultimately, I got the run down to just over 1 
> minute, and almost all of those gains are translatable to any Django site 
> running against a transactional DB. No changes to the apps themselves are 
> needed. I'd love to push some of this work upstream, if there's interest (or 
> even lack of opposition ;-)).
> 
> The speedups came from 3 main optimizations:
> 
> 1. Class-level fixture setup
> 
> Given a transaction DB, there's no reason to reload fixtures via dozens of 
> SQL statements before every test. I made use of setup_class() and 
> teardown_class() (yay, unittest2!) to change the flow for TestCase-using 
> tests to this:
> a. Load the fixtures at the top of the class, and commit.
> b. Run a test.
> c. Roll back, returning to pristine fixtures. Go back to step b.
> d. At class teardown, figure out which tables the fixtures loaded into, 
> and expressly clear out what was added.
> 
> Before this optimization: 302s to run the suite
> After: 97s.
> 
> Before: 37,583 queries
> After: 4,116
> 
> On top of that, an additional 4s was saved by reusing a single connection 
> rather than opening and closing them all the time, bringing the final number 
> down to 93s. (We can get away with this because we're committing any 
> on-cursor-initialization setup, whereas the old TestCase rolled it back.)
> 
> Here's the code: 
> https://github.com/erikrose/test-utils/blob/master/test_utils/__init__.py#L121.
>  I'd love to generalize it a bit (to fall back to the old behavior with 
> non-transactional backends, for example) and offer it as a patch to Django 
> proper, replacing TestCase. Thoughts?
> 
> (If you notice that copy-and-paste of loaddata sitting off to the side in 
> another module, don't fret; in the patch, that would turn into a refactoring 
> of loaddata to make the computation of the fixture-referenced tables 
> separately reusable.)
> 
> 
> 2. Fixture grouping
> 
> I next observed that many test classes reused the same sets of fixtures, 
> often via subclassing. After the previous optimization, our tests still 
> loaded fixtures 114 times, even though there were only 11 distinct sets of 
> them. So, I thought: why not write a custom testrunner that buckets the 
> classes by fixture set and advises the classes that, unless they're the first 
> or last in a bucket, they shouldn't bother tearing down or setting up the 
> fixtures, respectively? This took the form of a custom nose plugin (we use 
> nose for all our Django stuff), and it took another quarter off the test run:
> 
> Before: 97s
> After: 74s
> 
> Of course, test independence is still preserved. We're just factoring out 
> pointlessly repeated setup.
> 
> I don't really have plans to upstream this unless someone calls for it, but 
> I'll be making it available soon, likely as part of django-nose.
> 
> 
> 3. Startup optimizations
> 
> At this point, it was bothering me that, just to run a single test, I had to 
> wait through 15s of DB initialization (mostly auth_permissions and 
> django_content_type population)—stuff which was already perfectly valid from 
> the previous test run. So, building on some work we had already done in this 
> direction, I decided to skip the teardown of the test DB and, symmetrically, 
> the setup on future runs. If you make schema changes, just set an env var, 
> and it wipes and remakes the DB like usual. I could see pushing this into 
> django-nose as well, but it's got the hackiest implementation and can 
> potentially confuse users. I mention it for completeness.
> 
> Before: startup time 15s
> After: 3s (There's quite a wide variance due to I/O caching luck.)
> 
> Code: https://github.com/erikrose/test-utils/commit/b95a1b7
> 
> 
> If you read this far, you get a cookie! I welcome your feedback on merging 
> optimization #1 into core, as well as any accusations of insanity re: #2 and 
> #3. FWIW, everything works great without touching any of the tests on 3 of 
> our Django sites, totaling over 2000 tests.

I would be very happy to test this against Oracle database to see is how
much 

Re: Use case for #14914 (to_db_python)

[Jani Tiainen]

Hi,

You seem to found kind of an issue which happens with GeoDjango part as well. 
Most of the geodjango operations require quite heavy to/from data mangling 
while reading and/or writing data.

Currently there isn't clean solution to tell (per field) how data should be 
treated per backend. Django ORM works pretty well for a primitives like 
numbers, strings and such but when it goes to complex datatypes (like your 
encrypted field).

It would be really useful to have something to allow data mangling on a when 
reading/writing data from/to database per backend basis. Unfortunately such a 
feature isn't easy to implement due the current way how ORM works.

If you require such a functionality now, you should take a look how different 
GeoDjango backends deal with the similiar problem.

On Thu, 1 Aug 2013 21:23:40 -0700 (PDT)
Alejandro Dubrovsky  wrote:

> Looking around for a way to get the connection on deserialisation, I ran 
> into #14914  which was closed 
> wontfix 3 years ago with a request for a use case for the change.
> 
> Here is my use case:
> 
> I'm writing an encrypted char field, with encryption happening at the 
> database end (MS-SQL). Decryption looks a bit like this:
> 
> 
> OPEN SYMMETRIC KEY keyname
> DECRYPTION BY CERTIFICATE somecertificate
> 
> SELECT CAST(DECRYPTBYKEY(fieldname) AS VARCHAR(2048))
> FROM atable
> 
> CLOSE SYMMETRIC KEY keyname
> 
> 
> and analogously for the encryption.
> 
> The way I thought of doing that was by modifying get_db_prep_value for 
> encryption and to_python for decryption, but I ran into the lack of 
> connection at the to_python stage, and nothing like to_db_python.
> Does this constitute a legitimate use case for to_db_python or is there a 
> better way to go about this?
> Note: I'd prefer if any discussion would stay away from the validity of 
> using DB-based symmetric encryption on specific fields.
> 
> In the more general sense, I'd expect the method to be useful for any 
> stored-procedure-heavy location where the extracted field has to be 
> post-processed by some function that runs on the database to be made sense 
> of.
> 
> Thanks
> 
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecation a little harsh?

[Jani Tiainen]

Hi,

We've been able to do quite painless upgrades to our software as well.

Considering that we started with Django 1.1, stuck quite while at 1.3 and 
recently we did upgrade to 1.5

Most notable change was {% url %} tag, but nothing really major. 

Though we don't use many external libs - we've built our own.

Only real problem we have is that our deployment system sucks with the fact 
that it had for a long time shared libraries (including Django) which did had 
some impact on upgrades but since moving towards virtualenv usage we've been 
able to get rid of that problem as well, but that has nothing to do with actual 
Django.

Line count wise we hit quite similar as Florian:

main project consists:
~200 models,

.py 44805 lines
.html 143937 lines
.js 101317 lines (this is explained that we use dojotoolkit/extjs4 based single 
page app)

And our library:
.py  25079 lines
.js 25500 lines

And my 2 cents here - 

What I really like that Django getting new, better features while keeping very 
good deprecation policy. And yes, that sometimes requires that I lose few hours 
of sleep while upgrading but eventually it has to be done - it's just that I 
can't sit forever on same version. Sooner it's done easier it is and less time 
it takes. 


On Tue, 13 Aug 2013 13:16:01 -0400
François Schiettecatte  wrote:

> Florian
> 
> Here are wc -l line counts:
> 
> Project 1
> .py 28574
> .html 16967
> (this is a little misleading because we don't use model.py but a separate 
> REST API to handle all the storage)
> 
> 
> Project 2
> .py 43199
> .html 91804
> 
> 
> Project 3
> .py 32441
> .html 86684
> 
> 
> Cheers
> 
> François
> 
> 
> On Aug 13, 2013, at 12:31 PM, Florian Apolloner  wrote:
> 
> > Hi François,
> > 
> > On Tuesday, August 13, 2013 5:46:10 PM UTC+2, François Schiettecatte wrote:
> > I have done 1.3.x -> 1.4.x -> 1.5.x and they have all been painless, each 
> > migration taking less than 1/2 day. Point being that back-porting is not 
> > something I would ever need. 
> > 
> > It's good to hear that some people are keeping up2date and it didn't cause 
> > any pain! Do you mind sharing how big (lines of code wise) those apps are 
> > (just a rough classification).
> > 
> > Regards,
> > Florian
> > 

-- 

Jani Tiainen

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Jobs available

[Jani Tiainen]

Hi everyone.

Company I work for is looking for several full stack developers. Django,
GIS, Oracle and Postgres are some of the tools we're working with.

Work is located in Joensuu, Finland (no remote possibility). We can help
with relocation if necessary, even outside EU.

Open applications can be sent to care...@keypro.fi

-- 
Jani Tiainen
Team Lead / Utilities networks

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oc-RFcRcfMo%3D3jyzBP13dEkdG6Nn5dwygfXKtxrx%2BVicw%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Jani Tiainen]

Hi.

I would be really favorable suggested approach which would open up more
possibilities to responses. And in general sounds good direction.

su 17. marrask. 2019 klo 10.00 Adam Johnson  kirjoitti:

> Right - Flask's error message also points to something I was mistaken
> about. XMLHttpRequest does not set this header. jQuery adds it (
> https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and
> presumably some other JS libraries.
>
> In my opinion there are not many good reasons to have to change behaviour
>> if a request is made via XHR. I think the most common usage is to have a
>> single view that returns a JSON response or a HTML response depending on if
>> XHR is used (
>> https://github.com/search?l=Python&q=request.is_ajax&type=Code), which
>> isn’t great and isn’t reliable.
>>
>
> Riight too. A better way would be to check the Accept header. DRF does
> this: https://www.django-rest-framework.org/api-guide/content-negotiation/
> . Django doesn't provide any tools at the moment for parsing Accept. We
> could add an API like https://pypi.org/project/django-accept-header/ ?
>
> On Sat, 16 Nov 2019 at 16:16, Tom Forbes  wrote:
>
>> I would agree. Flask has done the same:
>>
>> DeprecationWarning: Request.is_xhr is deprecated. Given that the
>> X-Requested-With header is not a part of any spec, it is not reliable
>>
>> In my opinion there are not many good reasons to have to change behaviour
>> if a request is made via XHR. I think the most common usage is to have a
>> single view that returns a JSON response or a HTML response depending on if
>> XHR is used (
>> https://github.com/search?l=Python&q=request.is_ajax&type=Code), which
>> isn’t great and isn’t reliable.
>>
>>
>> On 16 Nov 2019, at 16:08, Adam Johnson  wrote:
>>
>> Django's HttpRequest.is_ajax method determines whether the request was
>> made with the JS API XMLHttpRequest
>> https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
>> . It does so by checking the X-Requested-With header.
>>
>> The new way of making "AJAX" requests from the browser is the JavaScript
>> fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
>> .
>>
>> I think the  is_ajax() documentation is at least a little misleading in
>> pretending XMLHttpRequest is the only JS API. There also aren't any special
>> headers set by fetch() so it's not possible to detect its requests.
>>
>> I propose deprecating is_ajax() with no replacement.
>>
>> Thoughts?
>>
>> --
>> Adam
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM12ozNou4y6s-AktSwnMfBLDR5FJjYAw-n0kofZ3%3DYtoA%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofvv3JXppzfGojGgOrQSRrXPhwAMmt_xos4GUsi_BFZdA%40mail.gmail.com.

Re: Hello/thoughts on JsonResponse

[Jani Tiainen]

Hi,

Since your proposal can live easily out of Django core as a 3rd party 
functionality you should start by implementing it, rather than waiting 
for official green light.


And that as said, since it can live very easily outside of Django you 
should really convince that this is something worth of including in the 
core. Or is there something that can't be done without changing Django 
internals?



On 6.9.2017 17.32, Ryan Fredericks wrote:

Hello everyone,

My name is Ryan and I've had the pleasure of working on various Django 
backed projects for the last three or four years.  I've never 
contributed to the project (yet) but I'd like to get started.  I'm 
posting today because I'd like to discuss something that has irked me 
about JsonResponse for a while.  I would love to submit a new PR for 
the feature I'm about to describe, but I just wanted to run it by you 
all and hear some thoughts first.


Currently Django can grab data as QuerySets.  Those QuerySets are 
easily serializable as json (or xml or whatever) via 
django.core.serializers.  Since it is so easy to serialize a QuerySet 
as json, wouldn't it follow that JsonResponse could handle a QuerySet? 
 Currently it does not, which leaves the following 2 workarounds: 1) 
manually set the content-type header in an HttpResponse, or 2) write 
some sort of crazy class that extends the json dumps encoder and pass 
that through to JsonResponse.  I know its not a huge deal, but how 
would you guys feel about either:


A - detecting if the object passed to JsonResponse is a QuerySet and 
then serializing it appropriately using the built in Django serializer 
instead of json dumps


B - Providing that json dumps encoder class to allow people to simply 
include that when they want to pass in a QuerySet to a JsonResponse.



I'd be happy to write something up and submit a PR if you guys think 
its worth it/a good place to start contributing.


Here's to hoping I can help contribute to many (much more) cool things 
in the future,

Ryan
--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/01c11ccd-6017-44e4-b31a-0f5bb08b386d%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/01c11ccd-6017-44e4-b31a-0f5bb08b386d%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/19fecb64-6a3a-ba57-5654-9a8c1718a34a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database agnostic EnumField

[Jani Tiainen]

Hi.

In general features that can live outside Django (doesn't require changes
in Django core to be implemented) needs quite well established de facto
standard in community to be included in the Django itself.

So best thing to do is to make sure that your implementation can work with
all current backends and preferably with all current supported Django
versions.

And get users to your enum field.


20.10.2017 14.55 "Ashley Waite"  kirjoitti:

I've been working a bit on an EnumField implementation because it'll save
me a lot of future time in a project, and existing implementations seem to
be fragile, non-reversible, or one-database-only. Wondering why there isn't
a PEP435 based EnumField in Django itself, I didn't find many answers with
a search on the mailing list.

Is this a feature that would be considered, and if so, what would the
expectations on it be?

I was a bit reluctant on all the implementations I could find because they
seem to reduce to these issues:
* Using an int/char instead of database enum
* Being database vendor specific
* Requiring a non-standard enum or sub-class of it
* Not allowing enum reuse
* Not migrating changes statefully (ie, injecting type declaration on
connection in postgres)
* Not allowing enum changes (add/remove/rename)
* Not parametising enum values (mysql)
* Not handling data consistency on enum changes

And realised, maybe that's why it's not a standard field.

I've done a POC implementation that works for mysql and postgres, and
should be able to easily generalise to work on any database via two flags
(has_enum, and requires_enum_declaration) that determine how to deal with
changes to it.

It addresses all of these issues, migrates, and with a little more work can
handle data effects as well.

So where should I go with this from here?
https://github.com/ashleywaite/django-more/tree/master/django_enum

- Ashley

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/317b5aea-b68f-467b-886d-68a49c7194c7%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofgo8WKq8N2LA6v-mKp5249Xtcg09B04Poqe_NMAGisAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rate limiting failed login attempts/failed password changes

[Jani Tiainen]

Hi,

There exists ticket already in Trac:

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

On 15.11.2017 13.07, Bernhard Posselt wrote:

Hi guys,

We've received a report from hackerone.com that our password change 
and login forms are not protected against brute forcing passwords. 
Since we re-use both the built-in password change and login form views 
from Django it feels like rate limiting for these views should work 
out of the box.


Using third-party extensions for this is certainly an option but I 
already have trouble to upgrade to newer versions with my existing 7 
django extensions and it feels like this feature should be implemented 
for every Django installation that uses contrib.auth.


What are your thoughts on this?

regards

Bernhard Posselt



--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ea82dbf2-c098-6f75-9d89-56739aa4a5ce%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security middleware for django for insecure (http) connections

[Jani Tiainen]

Hi,

Also there exists HTTPS devserver (at least one is 
https://github.com/teddziuba/django-sslserver ) which does it's job 
pretty well. Used it when had to demonstrate javascript location 
services (which do require HTTPS at least on chrome).


So I'm pretty convinced that this subject can be done without changes to 
Django core to demonstrate it's usefulness in real world use cases.


On 16.1.2018 9.17, Shai Berger wrote:

Hi Vishwas,

Can you state the circumstances in which this middleware will be
useful? Note that with the help of Let's Encrypt[1], a HTTPS
certificate is freely available to anyone, so there is no financial
barrier to using it.

Over and beyond the subject matter, is there anything preventing
implementation of your proposed middleware as an external package?
  If there is, please let us know, perhaps there is a missing API we
  need to add. If there isn't, then it would be better to do it that way
  first -- so your method can be tested in real use before we consider
  putting it into the framework.

Hope this helps,
Shai.

[1] https://letsencrypt.org/



--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31abd456-aa2e-8fe8-d1b3-85ee8ac3302c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Contribution

[Jani Tiainen]

Hi,

Pick one and give it a try. Don't worry if you don't get it right at the 
first time, people will help you get through eventually.



On 25.1.2018 13.20, 'Anoosha Masood Keen' via Django developers 
(Contributions to Django itself) wrote:
Hi , I want to contribute to Django. I have seen basic documentation 
provided by django and I had a look at the easy tickets. But I don't 
understand anyone of them. Any help would be appreciated.

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4e18651f-bfcb-4178-b9f4-80efae00abc9%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/4e18651f-bfcb-4178-b9f4-80efae00abc9%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cb7abcfa-8ff3-c052-fa99-3c847ea9e489%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On adding comments to database schema

[Jani Tiainen]

Oracle supports comments as well.

7.3.2018 2.52 ip. "vanadium23"  kirjoitti:

> Hello, fellows.
>
> There was once a proposal about ability to add comments to table/columns
> in postgres: https://code.djangoproject.com/ticket/18468
> I re-read discussion in ticket, and it has ended with another proposal,
> that now migrations is within Django, so we can add this feature.
>
> I want to make it as a third-party libs, but has come to thought that need
> to extend SchemaEditor, but it's not good for maintainability.
> Also, not only postgres has this feature, but also MySQL.
>
> Motivation for this feature is that some sort of users can view code
> comments without access to VCS of the project.
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/484264c0-b7d1-4264-b8b5-
> 8857847f6b53%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oesnBvY-mWXoHWa3sf8Vri%2B1qwRHat1yF%2B8Sdm0pU-LhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Jani Tiainen]

Hi.

As pointed out I believe this is not getting accepted as GSoC project for
Django.

But if you really believe that your approach is beneficial to larger
audience and you feel that it is right thing to do just do it. It is only
way to prove that you're right. Of course you could be wrong as well but
hey at least you did tried.

Having JavaScript builder pipeline might provide more fruitful though
getting such as GSoC project is really long shot.



la 17. maaliskuuta 2018 klo 6.49 Manasvi Saxena 
kirjoitti:

> Hello Sir,
>
> Hey Manasvi,
>>
>> I'm perhaps a bit biased but I would be very interested in anything that
>> can make JavaScript a real first class citizen in Django. There are a
>> number of third party packages out there that attempt something like this
>> (i.e django-webpack-loader). Django is classically quite conservative,
>> and up until relatively recently the JavaScript ecosystem has been in flux
>> with a relatively high amount of churn when it comes to build tools and
>> best practices.
>>
>> Things have somewhat stabalized recently with webpack achieving
>> widespread adoption so perhaps it's time to evaluate the landscape and see
>> if we can improve in this area. I'd love to see some kind of pluggable
>> JavaScript build system that would make modern JavaScript a first class
>> citizen alongside templates and other static assets, separate or as an
>> extension to the classic static assets functionality in Django.
>>
>
>> All in all I am quite jealous of how Rails handles JavaScript
>> integrations[1]. Again, this is just my personal opinion and I cannot say
>> if pursuing this will in any way effect your chances of being accepted but
>> this seems likes really interesting direction to investigate and more
>> practically useful than yet another way of generating static server side
>> HTML.
>>
>> Tom
>>
>
>
> Thank you for this new approach that you have shared. I would love to work
> on it since I have the required skills in both HTML and JavaScript to do
> this.
> I'll make a new proposal keeping in mind what you have suggested and will
> get back to you as soon as I have it ready.
> Would really love to know your views on that too.
> Thank you so much for the advice.
>
> Regards,
> Manasvi Saxena
>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/00e13803-b9af-4c76-9f0d-9d1f226c0acf%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oeKEmdRAwBqWjeBdt2BbT9aYsrUnBMoUAL0tD4Mg6Jnug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Jani Tiainen]

Hi.

Yes I read your initial proposal and in my experience putting any frontend
stuff to python code is disaster. Hard to maintain hard to understand when
pages do get more complex.

In my understanding it is also general consencus and for that reason Django
itself moved form widget rendering from python code to template based
widgets.

la 17. maaliskuuta 2018 klo 9.26 Manasvi Saxena 
kirjoitti:

> Hello,
>
> On Saturday, March 17, 2018 at 12:42:50 PM UTC+5:30, Jani Tiainen wrote:
>>
>> Hi.
>>
>> As pointed out I believe this is not getting accepted as GSoC project for
>> Django.
>>
>> But if you really believe that your approach is beneficial to larger
>> audience and you feel that it is right thing to do just do it. It is only
>> way to prove that you're right. Of course you could be wrong as well but
>> hey at least you did tried.
>>
>> Having JavaScript builder pipeline might provide more fruitful though
>> getting such as GSoC project is really long shot.
>>
>
>
> Did you go through what my initial idea was? what do you think of that?
> the pyhtml library and assisting Django templating language. Do you have
> any suggestions on how I can improve that too?
> Also, can you through some light on what you said about JavaScrip builder
> pipeline?
> I could really use your valuable feedback.
>
> Regards,
> Manasvi Saxena
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofs-e7yHSfLZC0feEbi%2B_aYEa3%2B329Rd%3DGC%2BVyco6HL%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Jani Tiainen]

Hi.

About javascript pipeline.

Basically having (pluggable) toolchain and practices to manage JavaScript
assests or stylesheets for example.

Tom Forbes described it quite well in his latter message.

la 17. maaliskuuta 2018 klo 9.49 Manasvi Saxena 
kirjoitti:

> Hello Sir,
>
> On Saturday, March 17, 2018 at 1:16:15 PM UTC+5:30, Jani Tiainen wrote:
>>
>> Hi.
>>
>> Yes I read your initial proposal and in my experience putting any
>> frontend stuff to python code is disaster. Hard to maintain hard to
>> understand when  pages do get more complex.
>>
>> In my understanding it is also general consencus and for that reason
>> Django itself moved form widget rendering from python code to template
>> based widgets.
>>
>> la 17. maaliskuuta 2018 klo 9.26 Manasvi Saxena 
>> kirjoitti:
>>
>>> Hello,
>>>
>>> On Saturday, March 17, 2018 at 12:42:50 PM UTC+5:30, Jani Tiainen wrote:
>>>>
>>>> Hi.
>>>>
>>>> As pointed out I believe this is not getting accepted as GSoC project
>>>> for Django.
>>>>
>>>> But if you really believe that your approach is beneficial to larger
>>>> audience and you feel that it is right thing to do just do it. It is only
>>>> way to prove that you're right. Of course you could be wrong as well but
>>>> hey at least you did tried.
>>>>
>>>> Having JavaScript builder pipeline might provide more fruitful though
>>>> getting such as GSoC project is really long shot.
>>>>
>>>
>>>
>>> Did you go through what my initial idea was? what do you think of that?
>>> the pyhtml library and assisting Django templating language. Do you have
>>> any suggestions on how I can improve that too?
>>> Also, can you through some light on what you said about JavaScrip
>>> builder pipeline?
>>> I could really use your valuable feedback.
>>>
>>> Regards,
>>> Manasvi Saxena
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>
>
> Also, can you through some light on what you said about JavaScrip builder
> pipeline?
>
> Regards,
> Manasvi Saxena
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ef819f36-9ace-4613-8c38-423a36677638%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ef819f36-9ace-4613-8c38-423a36677638%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ocgV%3D-9%3D7UmV1v1Ze36j_MOjerxe-x61eOuw1mVhjxEmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: adding object level permissions on the core permissions

[Jani Tiainen]

Hi.

To achieve object level permissions you need to write custom authentication
backend.

Django does provide support for object level permissions but there isn't
default implementation because object level permissions have different
meaning for different people.

See auth docs for more information.

to 29. maaliskuuta 2018 klo 17.37 Erick Lestrange mr-programs.com <
livingandwast...@gmail.com> kirjoitti:

> I want to add object level permissions to the Django'd core auth app
> Permission model.
>
> currently permission instances follow this string format
> '._' ideally i want this object level permissions to
> follow a similar string format with as few variations from the originals as
> possible
>
> but the main thing this permissions should do is being automatically
> loaded by the template system just as current ones in order to avoid db
> queries. this is a must!
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9651514e-60dc-4bd5-a33e-64b6d36481b2%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91odL6C2V-v_t4Qjo%2BXTwLztm6PNgLZDF6TGSwRZpELshYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: going through the django tutorial i found error while executing the python manage.py runserver.The error is attached below

[Jani Tiainen]

Hi.

You have a typo in your models.py

It should be ForeignKey not Foreignkey. Note the capital K.

6.5.2018 22.05 "Avitab Ayan Sarmah"  kirjoitti:

views.py:

from django.shortcuts import get_object_or_404, render

from . models import Question

def index(request):
latest_question_list = Question.objects.order_by('-pub_date')[:5]
context = {'latest_question_list': latest_question_list}
return render(request, 'polls/index.html', context)

def detail(request, question_id):
question = get_object_or_404(Question, pk=question_id)

def results(request, question_id):
response = "You're looking at the results of question %s."
return HttpResponse(response % question_id)

def vote(request, question_id):
return HttpResponse("You're voting on question %s." % question_id)

detail.html:

{{ question.question_text }}

{% for choice in question.choice_set.all %}
  {{ choice.choice_text }}
{% endfor %}


index.html:

{% if latest_question_list %}
  
  {% for question in latest_question_list %}
{{
question.question_text }}
  {% endfor %}
  
{% else %}
  No polls are available.
{% endif %}

mysite/polls/urls.py:

from django.urls import path

from . import views

urlpatterns = [
# ex: /polls/
path('', views.index, name='index'),
# ex: /polls/5/
path('/', views.detail, name='detail'),
#ex: /polls/5/results/
path('/results/', views.results, name='results'),
#ex: /polls/5/vote/
path('int:question_id>/vote/', views.vote, name='vote'),
]

mysite/urls.py:

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
path('', include('polls.urls')),
path('admin/', admin.site.urls),
]


please check these codes and comment where i've gone wrong

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/935bc46e-469f-4a60-882c-8c8c32cc85fe%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ocKh8G3NYAxDoa_57fHNKjdSHqZK6UBCydB3YrvbNf3Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Jani Tiainen]

Johannes Hoppe  kirjoitti ma 26. marrask. 2018 klo
11.05:

>
> On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
>>
>> Hi,
>>
>> I personally agree with Mariusz here. Oracle might have it's own quirks,
>> but the same could be said for any database. Taking my experience with the
>> ORM into account I do not think that Oracle requires much more work (if at
>> all) than any other database. I think in the end it does not matter whether
>> one works around the limitations/features of Oracle or MySQL. All in all I
>> think having Oracle is a good thing because databases like MSSQL and
>> Informix/DB2 quite often behave similar to Oracle and just narrowing the
>> core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.
>>
>> Granted, Oracle might be a bit harder to install; but with the developer
>> VMs and docker containers that argument doesn't really hold either imo.
>>
> There is not official container and the one you can build from their repo,
> didn't work for me. Furthermore you need to register with oracle and give
> them your Phone number, just to download the python library bindings. So it
> is somewhat harder than others ;)
>
>>
I've very successfully built docker images from Oracle official repo
without any major problems.

Also since cx_Oracle 6 you can build db api bindings without oracle sdk
libraries with simple pip install. Using those though requires client libs.

Not sure about registration process and is it needed for instant client or
xe version.


>> Cheers,
>> Florian
>>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/be871f78-76b7-4c52-8172-748248347b82%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ocaJHSSNKM2NB_PAEHude1vyb2apS0n3L9-E-vJecmvsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consensus about visual diagrams in the docs.

[Jani Tiainen]

Personally I use plantuml to generate various diagrams. It is open source
there even exists plugin for sphinx. It uses relatively understandable
diagram language. Exports svg along the many other formats. And there are
realtime preview plugins to most editors and ides.

Only big downside is that requires java runtime.

Curtis Maloney  kirjoitti pe 30. marrask. 2018 klo
21.47:

> On 11/30/18 7:38 PM, guettli wrote:
> > I do not care for the strategy, I care for the goal.
> >
> > How to find clear consensus now?
>
> There is a time honored practice in open source of spurring more
> spirited discussion by presenting a solution, however sub-optimal it may
> be.
>
> It may not be the accepted solution, but it's far more likely to get
> people to give input than asking for discussion.
>
> [No, I'm not just wrapping up "patches welcome" - this is a general
> observation in life. It's just more openly recognised in OSS :) ]
>
> --
> Curtis
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/88fbd91d-e4ee-89ac-5bae-1c54f7560698%40tinbrain.net
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofesmCYF8dF81KGqL4SRgrHyCRyiWO-2mB%3Dc6HW-Q%3Dysg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

[Jani Tiainen]

Hi.

Does this require changes to django internals or can it work as an external
package?

Also you should release it as a package so people can start using it, also
preferably releasing it with BSD license like Django itself is. Otherwise
there are very little chances that your solution would make to django it
self.

Improvements to rendering are always welcome, but they must come without
too much maintenance burden.

On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos 
wrote:

> Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@gmail.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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91odKFPEc96hbTLmuckAdhmf9LHykEvk--J%3D5vjNmyVGF5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

[Jani Tiainen]

Hi,

Lets try this again.

Your system could be nice if it really helps rendering speed.

But does it require changes in Django core itself, or is it completely
standalone package that doesn't require changing Django itself to operate?
If it requires changes in Django itself, it would be useful to describe
what changes are needed and why.

Note that you can even no build custom rendering engines since Django
supports those now (with default implementations for Django Templating
Language and Jinja2) your system actually might fall in this category.

Even code is bad you really need to start get some momentum for your
system. Otherwise it's really hard to provide any feedback for example
there might be some edgecases you might not have thought of.


On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
wrote:

> Sorry, I reply beetween lines
>
> El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
> escribió:
>
>> Hi another time,
>>
>> I am tring to reply every people in this email:
>>
>> Josh
>>
>> I was not using django.template.loaders.cached.Loader, but the result are
>> very similar i.e:
>>
>> App Template Num templates rendered before unify Num templates rendered
>> after unify AVG Time render template before unify (ms) AVG Time render
>> template after unify (ms)
>> Django admin admin/index.html 3 1 80 70
>> Django constance admin/constance/change_list.html 7 1 330 180
>> Django su su/login.html 5 3 10 5
>>
>> Pavlos:
>>
>>1. Yes, I wrote this email to contribute another time. Actually I am
>>already Django contributor[1][2]
>>2. I didn't share my code, because it is not a nice code. *For me it
>>is a teoric question. I don't want anybody have a bad opinion of this
>>proposal for the implementation*. But I am sharing [3] it without
>>problems, but please I know this solution is incomplete for many reason.
>>3. About your question: "I am not sure I understood anything so far.
>>Are you just pre-rendering {% include %} tags, so the template engine
>>doesn't have to do that in runtime?" Yes :-)
>>4. About it: "I think what you did is addressed more neatly with the
>>django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
>>"Experimenting like this, even if you end up rediscovering something that
>>exists" It is something different than django cache loader, of course I
>>know django cache loader, I fixed a problem with django cached loader [4]
>>five years ago :-). With django cache loader, we get django get a template
>>quickly. But If your view finally render 3 templates, django cached loader
>>will have to get 3 templates (from cache). With my proposal your view
>>render only 1 template (This is not 100% true, 1 + templates about
>>templatetags except extends and include)
>>
>> Jani:
>>
>> Currently you only need move the new template result to the old path of
>> the template. But it is only because I want. If you change this line [5]
>> for this other you don't need any change:
>>
>> destination_name = template.origin.name
>>
>>
>> 8 years ago I requested a feature related with templates
>>
>
> [6]
>
>
> , now I have a new request :-) 8 years ago I tried resolved my proposal,
>> now I only want propose something :-D
>>
>> I think in this change for Django :-)
>>
>>
>> REF's
>>
>> 1.
>> https://github.com/django/django/pulls?q=is%3Apr+author%3Agoinnn+is%3Aclosed
>> 2.
>> https://code.djangoproject.com/query?status=assigned&status=closed&status=new&reporter=~pmartin&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id
>> 3. https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6
>> (tested in Django 1.8 - 1.11)
>> 4.
>> https://github.com/django/django/pull/1936/commits/e669bca5c8fe6d13ea745d338203cd9e7470ae6b
>> 5.
>> https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6#file-unify_templates-py-L58
>> 6. https://code.djangoproject.com/ticket/15053
>>
>>
>> Best,
>>
>>
>> El vie., 18 ene. 2019 a las 14:11, Jani Tiainen ()
>> escribió:
>>
>>> Hi.
>>>
>>> Does this require changes to django internals or can it work as an
>>> external package?
>>>
>>> Also you should release it as a package so people can start using it,
>>> also preferably releasing it with BSD license like Django itself is.
>>&g

Re: What do you think about unify templates feature?

[Jani Tiainen]

Hi,

You said that this doesn't require any change in Django at all.

So this doesn't need to be in Django at all, it can survive as its own and
that way it should be.

So make your enhancement as reusable app and release it to public. Get
people to use it. Fix the bugs that appears. Write a good documentation.
Give the support.



On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
wrote:

> I reply beetween lines,
>
> El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
> escribió:
>
>> Hi,
>>
>> Lets try this again.
>>
>> Your system could be nice if it really helps rendering speed.
>>
>
> Yes we get several miliseconds per request.
>
>
>>
>> But does it require changes in Django core itself, or is it completely
>> standalone package that doesn't require changing Django itself to operate?
>> If it requires changes in Django itself, it would be useful to describe
>> what changes are needed and why.
>>
>>
> You don't need any change in Django. This command generates a new
> template. I paste another time my first example:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preprocess every template of a settings variable and I
> get something like this:
>
> news.unify.html (or if you want the command can overwrite news.html)
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> It is only a preprocess to get time for each request.
>
> Note that you can even no build custom rendering engines since Django
>> supports those now (with default implementations for Django Templating
>> Language and Jinja2) your system actually might fall in this category.
>>
>>
> No, It is not a new render engine. It would be a pre render engine. It is
> a new feature.
>
>
>> Even code is bad you really need to start get some momentum for your
>> system. Otherwise it's really hard to provide any feedback for example
>> there might be some edgecases you might not have thought of.
>>
>
> I want to know if this is a nice feature for Django community, then I will
> create a ticket... and if nobody resolve it I will propose a change, but I
> know ifor experience it is very hard collaborate with code in Django, and
> more difficult with a new feature.
>
> To understand it, the best is to use the command with a simple template
> such as admin/index.html.
>
> Best,
>
>
>>
>> On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
>> wrote:
>>
>>> Sorry, I reply beetween lines
>>>
>>> El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
>>> escribió:
>>>
>>>> Hi another time,
>>>>
>>>> I am tring to reply every people in this email:
>>>>
>>>> Josh
>>>>
>>>> I was not using django.template.loaders.cached.Loader, but the result
>>>> are very similar i.e:
>>>>
>>>> App Template Num templates rendered before unify Num templates
>>>> rendered after unify AVG Time render template before unify (ms) AVG
>>>> Time render template after unify (ms)
>>>> Django admin admin/index.html 3 1 80 70
>>>> Django constance admin/constance/change_list.html 7 1 330 180
>>>> Django su su/login.html 5 3 10 5
>>>>
>>>> Pavlos:
>>>>
>>>>1. Yes, I wrote this email to contribute another time. Actually I
>>>>am already

Re: What do you think about unify templates feature?

[Jani Tiainen]

Hi.

Unfortunately Django is already big. Every new feature requires careful
consideration since it adds maintenance burden to already loaded
maintainers.

So best and pretty much only way to make your feature appear in Django
itself is to prove that your solution is widely adopted in everyday use and
it's "winning" technology.

That would practically mean that code is well written, constantly
maintained and documented.

You can keep showing speed test results but they really won't get you
anywhere. Let the people decide is your feature good or not. Get more
contributors to your feature to resolve edge cases that doesn't work yet.


J. Pablo Martín Cobos  kirjoitti la 19. tammik. 2019 klo
10.22:

>
>
>
>
>
> El sáb., 19 ene. 2019 7:08, Jani Tiainen  escribió:
>
>> Hi,
>>
>> You said that this doesn't require any change in Django at all.
>>
>> So this doesn't need to be in Django at all, it can survive as its own
>> and that way it should be.
>>
>> So make your enhancement as reusable app and release it to public. Get
>> people to use it. Fix the bugs that appears. Write a good documentation.
>> Give the support.
>>
>>
> Yes, it is an option, or another option is convince for this feature is in
> Django.
>
> This doesn't need to be in Django, but I think, it is convenient, like any
> improve.
>
> Thanks!
>
>
>
>
>>
>> On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
>> wrote:
>>
>>> I reply beetween lines,
>>>
>>> El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
>>> escribió:
>>>
>>>> Hi,
>>>>
>>>> Lets try this again.
>>>>
>>>> Your system could be nice if it really helps rendering speed.
>>>>
>>>
>>> Yes we get several miliseconds per request.
>>>
>>>
>>>>
>>>> But does it require changes in Django core itself, or is it completely
>>>> standalone package that doesn't require changing Django itself to operate?
>>>> If it requires changes in Django itself, it would be useful to describe
>>>> what changes are needed and why.
>>>>
>>>>
>>> You don't need any change in Django. This command generates a new
>>> template. I paste another time my first example:
>>>
>>> 1. news.html
>>>
>>> {% extends "base.html" %}
>>>
>>> {% block title %}
>>> {% include "inc.news.title.html" %}
>>> {% endblock %}
>>>
>>> {% block content %}
>>> {% for news_item in news %}
>>> {{ news_item.title }}
>>> {{ news_item.subtitle }}
>>> {% endfor %}
>>> {% endblock %}
>>>
>>> 2. base.html
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>>> http://www.w3.org/1999/xhtml"; lang="{{
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>>> %}>
>>> 
>>> {% block title %}{% endblock %}
>>> 
>>> 
>>> {% block content %}{% endblock %}
>>> 
>>> 
>>>
>>> 3. inc.news.title.html
>>> News
>>>
>>> With this command I preprocess every template of a settings variable and
>>> I get something like this:
>>>
>>> news.unify.html (or if you want the command can overwrite news.html)
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>>> http://www.w3.org/1999/xhtml"; lang="{{
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>>> %}>
>>> 
>>> News
>>> 
>>> 
>>> {% for news_item in news %}
>>> {{ news_item.title }}
>>> {{ news_item.subtitle }}
>>> {% endfor %}
>>> 
>>> 
>>>
>>> It is only a preprocess to get time for each request.
>>>
>>> Note that you can even no build custom rendering engines since Django
>>>> supports those now (with default implementations for Django Templating
>>>> Language and Jinja2) your system actually might fall in this category.
>>>>
>>>>
>>> No, It is not a new render engin

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Jani Tiainen]

 discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> 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/KVAZkRCq9KU/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CBFA85F9-3EE1-4B74-B121-F178F551D9CD%40polytechnique.org
>>> <https://groups.google.com/d/msgid/django-developers/CBFA85F9-3EE1-4B74-B121-F178F551D9CD%40polytechnique.org?utm_medium=email&utm_source=footer>
>>> .
>>> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b36c1ba6-0473-47d3-87e5-6b2c5c9ecbf9%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/b36c1ba6-0473-47d3-87e5-6b2c5c9ecbf9%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ods4pS8t905EtFtUmkfomuNz4JTe-27Vx0XR-uqN-EwKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django include default user registration, forgot password, OTP feature by default with Django libraries

[Jani Tiainen]

Hi.

ke 13. maalisk. 2019 klo 18.19 parocks 
kirjoitti:

> I have been working with Django for small clients.
> One of the feature I would really love to have is
> 1. Default User Registration feature (without having to fiddle with things
> like the admin portal)
>

Registration is not a simple thing. There are quite many ways to make
registration happen which is the reason that Django doesn't have any
default implementation for it. You can find several goid 3rd party packages
that handles different kind of registrations.

Also you may find that some would like to handle registration by Facebook,
Google account, LDAP and who knows what else there exists.

2. Forgot password feature
>

Django has it already. It's called reset password in contrib.auth

3. OTP for all user registrations by default
>

OTP like by TOTP, SMS messages, email or USB dongles or some other means?

And don't you want to have it in login rather than just in registration?

Like you see it's not trivial.


> Those three are the missing ones from my opinion.
> If thats included I would say Django will beat most of the frameworks in
> the market.
>
> Looking forward for easy enablement of those 3 features natively into
> Django.
> Please consider documenting it in the api atleast.
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/02b42c58-edb5-4bab-b745-1dc985e264d1%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91od53ZUAxBgziRch5SZfqbRrf4fDEgt9cifA0Y5h2SiAwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jani Tiainen]

Well let me add my two cents here since I was also in the group in DCEU
that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a
comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually
depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't
get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some
other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In
my short experience with black (I've been using it for work projects) it
does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I
don't have to. Black does it for a "greater good". And after a while black
actually vanishes from the flow.

On Sat, Apr 13, 2019 at 6:35 PM Herman S  wrote:

> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I recommend reading the the projects
> README.
> The short version: it aims to reduce bike-shedding and non value-adding
> discussions; saving time reviewing code; and making the barrier to entry
> lower
> by taking some uncompromissing choices with regards to formatting.  This is
> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>
> Personally I first got involved contributing to Django couple of weeks
> back,
> and from anecdotal experience I can testify to how 'formatting of code'
> creates
> a huge barrier for entry. My PR at the time went multiple times back and
> forth
> tweaking formatting. Before this, I had to research the style used by
> exploring
> the docs at length and reading at least 10-20 different source – and even
> those
> were not always consistent. At the end of the day I felt like almost 50%
> of the
> time I used on the patch was not used on actually solving the issue at
> hand.
> Thinking about code formatting in 2019 is a mental energy better used for
> other
> things, and it feels unnecessary that core developers on Django spend
> their time
> "nit-picking" on these things.
>
> I recently led the efforts to make this change where I work. We have a
> 200K+
> LOC Django code-base with more than 30K commits. Some key take-aways: it
> has
> drastically changed the way we work with code across teams, new engineers
> are
> easier on-boarded, PR are more focused on architectural choices and "naming
> things", existing PRs before migration had surprisingly few conflicts and
> were
> easy to fix, hot code paths are already "blameable" and it's easy to blame
> a
> line of code and go past the "black-commit", and lastly the migration went
> without any issues or down-time.
>
> I had some really fruitful discussions at DjangoCon Europe this week on
> this
> very topic, and it seems we are not alone in these experiences. I would
> love to
> hear from all of you and hope that we can land on something that will
> enable
> *more* people to easier contribute back to this project.
>
> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no string normalization:
> https://github.com/hermansc/django/pull/2
>
> Please have a look at the Black documentation. It explains the benefits
> better
> than I possibly could do here.
>
> With kind regards,
> Herman Schistad
>
> [0]: https://github.com/ambv/black
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen
Software wizard

https://blog.jani.tiainen.cc/

Always open

Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project

[Jani Tiainen]

I'm definitely +1 too.


to 18. heinäk. 2019 klo 20.41 Adam Johnson  kirjoitti:

> +1 from me too.
>
> On Thu, 18 Jul 2019 at 17:55, Tobias McNulty 
> wrote:
>
>> I think it's a great idea.
>>
>> On Thu, Jul 18, 2019, 12:46 PM Jacob Kaplan-Moss 
>> wrote:
>>
>>> Hi folks -
>>>
>>> I’d like to gauge interest in adopting dj-database-url
>>> (http://github.com/jacobian/dj-database-url) as an official project
>>> (
>>> https://github.com/django/deps/blob/master/final/0007-official-projects.rst
>>> ).
>>> This is my pre-proposal. I think dj-database-url is very widely-used, and
>>> scratches a specific but annoying itch. Maintenance burden is minimal,
>>> but
>>> important.
>>>
>>> What do other folks think? DEP 7 asks us to
>>>
>>> > solicit feedback from the community and work out if there is rough
>>> agreement
>>> > that the project is a good thing for Django to adopt, particularly
>>> focusing on
>>> > any alternative approaches to the same problem and the relative merits
>>> of them,
>>> > including code design, scalability, alignment with existing Django
>>> design and
>>> > philosophy, and having an available development and maintenance team.
>>>
>>> So - thoughts?
>>>
>>> I'm volunteering to be the shepherd, but do intend to form a larger team.
>>>
>>> I've also opened https://github.com/jacobian/dj-database-url/issues/120
>>> as another place for this discussion. Please feel free to comment either
>>> place.
>>>
>>> [Backstory, and why this is living on my github right now. @kennethreitz
>>> was
>>> looking for a new maintainer, and reached out to me to see if Django
>>> might be
>>> interested. I thought perhaps so, and offered to take over
>>> maintainership in the
>>> meantime while we work through the DEP 7 process. If it turns out that an
>>> Official Project is the wrong home for this, I'll either maintain it
>>> long-term
>>> or transfer it again.]
>>>
>>> Jacob
>>>
>>> --
>>> 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark
>>> 
>>> .
>>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMGFDKRakWoQYehp_ccnhTvbQWY3a2CN2k_iob2fsL7bwv%2BRcQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3jWBjZVyFw-KmLRvuYaFO3p6KmYnF%3DoQNjTPR2NN%3D8Bg%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofUn-wQrurR2jM772jvGVxizXzAkZjzqr6PUutvM6xrLg%40mail.gmail.com.
For more options, visit ht

Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project

[Jani Tiainen]

Apparently there has been few attempts to integrate dj-database-url or some
other url parser.

But what happened to them since so far none of them were completed?


to 18. heinäk. 2019 klo 22.32 Raffaele Salmaso 
kirjoitti:

> Hi
> I'm working[¹] on https://github.com/django/django/pull/10786 which is an
> "evolution" of dj-database-url which handle more settings types (by default
> even the email settings, but it is possible to handle any other type).
> I'll happy to finish it.
>
> [¹] well, in my really little free time
>
> On Thu, Jul 18, 2019 at 6:45 PM Jacob Kaplan-Moss 
> wrote:
>
>> Hi folks -
>>
>> I’d like to gauge interest in adopting dj-database-url
>> (http://github.com/jacobian/dj-database-url) as an official project
>> (
>> https://github.com/django/deps/blob/master/final/0007-official-projects.rst
>> ).
>> This is my pre-proposal. I think dj-database-url is very widely-used, and
>> scratches a specific but annoying itch. Maintenance burden is minimal, but
>> important.
>>
>> What do other folks think? DEP 7 asks us to
>>
>> > solicit feedback from the community and work out if there is rough
>> agreement
>> > that the project is a good thing for Django to adopt, particularly
>> focusing on
>> > any alternative approaches to the same problem and the relative merits
>> of them,
>> > including code design, scalability, alignment with existing Django
>> design and
>> > philosophy, and having an available development and maintenance team.
>>
>> So - thoughts?
>>
>> I'm volunteering to be the shepherd, but do intend to form a larger team.
>>
>> I've also opened https://github.com/jacobian/dj-database-url/issues/120
>> as another place for this discussion. Please feel free to comment either
>> place.
>>
>> [Backstory, and why this is living on my github right now. @kennethreitz
>> was
>> looking for a new maintainer, and reached out to me to see if Django
>> might be
>> interested. I thought perhaps so, and offered to take over maintainership
>> in the
>> meantime while we work through the DEP 7 process. If it turns out that an
>> Official Project is the wrong home for this, I'll either maintain it
>> long-term
>> or transfer it again.]
>>
>> Jacob
>>
>> --
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABgH4JvLhqgd7VPPAdaCoJ3VidZ-JaPZVbU2gMiK3_Rycxnekw%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ocT86%2Bkz9dL0Rr6zKNOMXq9Ge%3Djj-%2B-bC4-jDyffbo9Sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: get user by session key

[Jani Tiainen]

Hi.

I have few times had a need to get user by session. For debugging purposes.

Also django-extensions do have management command to return user from
session id.

But I really can't imagine any usecase where just session would make
sense...

pe 26. heinäk. 2019 klo 19.40 Adam Johnson  kirjoitti:

> Hey,
>
> Welcome to the mailing list. This is probably a little low-level as a
> feature request here. I think it is better submitted as a ticket as per
> https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/
>  :)
> Where on the docs did you read about django-developers?
>
> As for your suggested feature - could you talk about your use case a
> little more? If Django is going to support sessions not attached to
> requests, it's likely this isn't the only thing that would need changing.
> And as you've seen in the source, the function you want right now is only
> one line (get_user_session_key).
>
> Thanks,
>
> Adam
>
> On Thu, 25 Jul 2019 at 14:09, 'andreymal' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> (Hello, the Django documentation says that I should send feature
>> requests to the django-developers mailing list, so I send it here.)
>>
>> I have a need to get a user object using a known session key without an
>> HTTP request. After reading the Django code, I did not find a clean way
>> to do this.
>>
>> Django has the "get_user" function that requires a request object. But
>> it actually uses only "request.session" and nothing else. So I suggest
>> refactoring it something like this:
>>
>> #
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py
>> def _get_user_session_key(session):
>> return get_user_model()._meta.pk.to_python(session[SESSION_KEY])
>>
>> def get_user(request):
>> return get_user_by_session(request.session)
>>
>> def get_user_by_session_key(session_key):
>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
>> return get_user_by_session(SessionStore(session_key))
>>
>> def get_user_by_session(session):
>> from .models import AnonymousUser
>> user = None
>> try:
>> user_id = _get_user_session_key(session)
>> backend_path = session[BACKEND_SESSION_KEY]
>> except KeyError:
>> pass
>> else:
>> ... # the rest of the code
>> return user or AnonymousUser()
>>
>> Note that Django Channels has similar code so the "get_user_by_session"
>> function can help to deduplicate it:
>> https://github.com/django/channels/tree/master/channels/auth.py#L23
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/858abfe1-42b9-185b-e69c-c23d6058e762%40andreymal.org
>> .
>>
>
>
> --
> Adam
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3vn6SP2q951_1keJnaQhAbTEY3rfK_X-FvSSLOtQoTCw%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ofHCsQB4mtwOW-vrvZKYMLCi_ecqR0tRKP0%2B-GyJSjVmg%40mail.gmail.com.

Re: Oracle DB table prefix missing

[Jani Tiainen]

Hi.

Unfortunately there currently isn't such a feature.

This would be interesting feature to have. Surely there are quite few edge
cases where prefixing would fail.

ti 17. syysk. 2019 klo 18.27 Christian González <
christian.gonza...@nerdocs.at> kirjoitti:

> Hi,
>
> I don't know if this is a missing feature. But after reading the code of
> django.db.backends.oracle.* I think that there is a feature missing - at
> least in the Oracle driver - you can't add a generic table prefix.
>
> I have a production Oracle database where a proprietary software does
> read/write operations. I created a Django ORM on top of it using
> 'inspectdb', but want to make sure that Django never-ever writes
> anything into that DB, not even on purpose (user accidentally clicks on
> "save" in admin UI). So I created a readonly user in Oracle who has
> readonly (SELECT) access to that database:
>
> CREATE USER testreadonly IDENTIFIED BY testreadonly DEFAULT TABLESPACE
> PROD_DB TEMPORARY TABLESPACE TEMPTBS2 QUOTA UNLIMITED ON PROD_DB;
>
> and gave him rights:
>
> GRANT connect, resource to testreadonly;   ## those are the two roles
> for access here
> GRANT SELECT ANY TABLE TO testreadonly;
>
> So far, so good.
>
> The problem is that, in SQL, as the "testreadonly" user's primary schema
> is not PROD_DB, I have to prefix every table name like:
>
> SELECT max(id) FROM PROD_DB.people
>
> There is a more or less unanswered stackexchange question too:
>
> https://stackoverflow.com/questions/49056244/prefix-all-table-names-django-1-11
>
> What would be a workaround is to add the prefix to the
> metaclass.table_name attribute of each model. Which sounds extremely
> un-pythonic to mee (DRY?)
>
> Ideally, I wished to have a "TABLESPACE" config field within the
> DATABASE entry which reflects the TBLSPACE setting which is provided by
> Django , but only within the DATABASES["TEST"] dict, or the
> "db_tablespace" option as attribute within a Model. Which is also DRY.
>
> Is there a chance that this could be worth an implementation?
>
> Or did I get something completely wrong and it's just my missing
> configuration?
>
> thanks,
>
> Christian
>
>
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/860c153a-2efc-86fb-4649-6ce3752f6e5b%40nerdocs.at
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oe6Tv7ZfFQvWXWJKv-8QQCdQKk8iuxOKKFFN8Rh0nWutQ%40mail.gmail.com.

Re: Oracle DB table prefix missing

[Jani Tiainen]

...

Also in Oracle you can create synonyms (private are enough) to get around
prefix.

And IIRC there is a way to set default schema for user but I that would
require executing piece of SQL after connection is made.

ti 17. syysk. 2019 klo 18.27 Christian González <
christian.gonza...@nerdocs.at> kirjoitti:

> Hi,
>
> I don't know if this is a missing feature. But after reading the code of
> django.db.backends.oracle.* I think that there is a feature missing - at
> least in the Oracle driver - you can't add a generic table prefix.
>
> I have a production Oracle database where a proprietary software does
> read/write operations. I created a Django ORM on top of it using
> 'inspectdb', but want to make sure that Django never-ever writes
> anything into that DB, not even on purpose (user accidentally clicks on
> "save" in admin UI). So I created a readonly user in Oracle who has
> readonly (SELECT) access to that database:
>
> CREATE USER testreadonly IDENTIFIED BY testreadonly DEFAULT TABLESPACE
> PROD_DB TEMPORARY TABLESPACE TEMPTBS2 QUOTA UNLIMITED ON PROD_DB;
>
> and gave him rights:
>
> GRANT connect, resource to testreadonly;   ## those are the two roles
> for access here
> GRANT SELECT ANY TABLE TO testreadonly;
>
> So far, so good.
>
> The problem is that, in SQL, as the "testreadonly" user's primary schema
> is not PROD_DB, I have to prefix every table name like:
>
> SELECT max(id) FROM PROD_DB.people
>
> There is a more or less unanswered stackexchange question too:
>
> https://stackoverflow.com/questions/49056244/prefix-all-table-names-django-1-11
>
> What would be a workaround is to add the prefix to the
> metaclass.table_name attribute of each model. Which sounds extremely
> un-pythonic to mee (DRY?)
>
> Ideally, I wished to have a "TABLESPACE" config field within the
> DATABASE entry which reflects the TBLSPACE setting which is provided by
> Django , but only within the DATABASES["TEST"] dict, or the
> "db_tablespace" option as attribute within a Model. Which is also DRY.
>
> Is there a chance that this could be worth an implementation?
>
> Or did I get something completely wrong and it's just my missing
> configuration?
>
> thanks,
>
> Christian
>
>
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/860c153a-2efc-86fb-4649-6ce3752f6e5b%40nerdocs.at
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oepYWx31VUALj8CWbjr-hfYh-Az%3DOp1sPw3VF3Yzmri0Q%40mail.gmail.com.

Re: Oracle DB table prefix missing

[Jani Tiainen]

You're right Oracle has quite few levels of storage definitions tablespaces
just being one.


ti 17. syysk. 2019 klo 19.20 Stephen J. Butler 
kirjoitti:

> Maybe I'm misunderstanding, but tablespace has to do with physical storage
> of the schema, not how tables are named. What you really want is a
> db_schema_name or something. I think this long, old ticket is related
> https://code.djangoproject.com/ticket/6148
>
> On Tue, Sep 17, 2019 at 10:27 AM Christian González <
> christian.gonza...@nerdocs.at> wrote:
>
>> Hi,
>>
>> I don't know if this is a missing feature. But after reading the code of
>> django.db.backends.oracle.* I think that there is a feature missing - at
>> least in the Oracle driver - you can't add a generic table prefix.
>>
>> I have a production Oracle database where a proprietary software does
>> read/write operations. I created a Django ORM on top of it using
>> 'inspectdb', but want to make sure that Django never-ever writes
>> anything into that DB, not even on purpose (user accidentally clicks on
>> "save" in admin UI). So I created a readonly user in Oracle who has
>> readonly (SELECT) access to that database:
>>
>> CREATE USER testreadonly IDENTIFIED BY testreadonly DEFAULT TABLESPACE
>> PROD_DB TEMPORARY TABLESPACE TEMPTBS2 QUOTA UNLIMITED ON PROD_DB;
>>
>> and gave him rights:
>>
>> GRANT connect, resource to testreadonly;   ## those are the two roles
>> for access here
>> GRANT SELECT ANY TABLE TO testreadonly;
>>
>> So far, so good.
>>
>> The problem is that, in SQL, as the "testreadonly" user's primary schema
>> is not PROD_DB, I have to prefix every table name like:
>>
>> SELECT max(id) FROM PROD_DB.people
>>
>> There is a more or less unanswered stackexchange question too:
>>
>> https://stackoverflow.com/questions/49056244/prefix-all-table-names-django-1-11
>>
>> What would be a workaround is to add the prefix to the
>> metaclass.table_name attribute of each model. Which sounds extremely
>> un-pythonic to mee (DRY?)
>>
>> Ideally, I wished to have a "TABLESPACE" config field within the
>> DATABASE entry which reflects the TBLSPACE setting which is provided by
>> Django , but only within the DATABASES["TEST"] dict, or the
>> "db_tablespace" option as attribute within a Model. Which is also DRY.
>>
>> Is there a chance that this could be worth an implementation?
>>
>> Or did I get something completely wrong and it's just my missing
>> configuration?
>>
>> thanks,
>>
>> Christian
>>
>>
>>
>> --
>> Dr. Christian González
>> https://nerdocs.at
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/860c153a-2efc-86fb-4649-6ce3752f6e5b%40nerdocs.at
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAD4ANxVRRxfuS90H13gvBZ8JfZF9TM_vXCbU6FhMFGJ5AjpdKw%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91ocSwP5dGgqRYDRfu-1ui68N0bcuqPdXZTDCndjJY_rqVA%40mail.gmail.com.

Re: Explore integrating django-docker-box in some way?

[Jani Tiainen]

IIRC correctly I had problems with alpine and it's GIS libraries when
preparing for my workshop on Djangocon EU 2019.

Most of the required libs weren't available in stable version. Haven't
checked if situation has improved since.


ti 8. lokak. 2019 klo 14.05 Tom Forbes  kirjoitti:

> I did experiment with it. The main problem is that the image we use
> requires a bunch of system libraries (see
> https://github.com/django/django-docker-box/blob/master/Dockerfile#L4). I
> think a few where missing our outdated in Alpine, but if that's changed
> then I'm not against trying it again.
>
> Tom
>
> On 8 Oct 2019, at 11:58, Nick Sarbicki  wrote:
>
> Just out of interest, Tom, have you tried using Alpine as the base? Or is
> there a reason to avoid it?
>
> I usually find once you introduce all the dependencies for django it
> doesn't make a huge difference but it might shave some of the weight off if
> we're worried about image size.
>
>
> - Nick
>
>
> On Tue, Oct 8, 2019 at 11:52 AM Josh Smeaton 
> wrote:
>
>> I was going to archive the repo, but it seems I don't have the necessary
>> permissions. Carlton, do you?
>>
>> On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote:
>>>
>>> +1 to archiving django-box
>>>
>>> On Tue, 8 Oct 2019 at 11:01, Tom Forbes  wrote:
>>>
 Thank you for the kind words Bruno! I'm glad it's helped you, if you
 have any suggestions for improvements then please open an issue on the repo
 or post a message here, I know it's not perfect. I would have replied
 earlier but this message didn't get delivered to me.

 I'm biased, but I'd be +1 on archiving the old django-box. It's served
 us well, but unless someone is willing to spend some time updating it then
 it's going to confuse new users.

 On Friday, 4 October 2019 12:40:02 UTC+1, Bruno Alla wrote:
>
> Just a note that as a newish contributor to Django, this
> django-docker-box is fantastic, it makes things much easier to setup.
>
> Thank you to everyone involved!
>
> On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>>
>> To have this completely working at sprints without having everyone
>> building their own local images we would need to have the Jenkins server
>> use docker in some capacity. This would also require an official
>> django account on Docker hub.
>>
>> The pattern I’m using right now is that on every build we pull the
>> django-ci:latest image (from my personal account). Docker uses this
>> image as a cache automatically (preventing rebuilds). On any successful
>> master build we push the new image to docker-hub, so subsequent builds 
>> can
>> utilise it.
>>
>> Then anyone wanting to speed up their bootstrapping can do docker-compose
>> pull and automatically have the latest image available for running
>> right away. We can make this smaller, for sure, but we can also suggest
>> people download this beforehand (i.e at their hotel).
>>
>> I don’t know how feasible this is but it’s also very easy to run a
>> caching docker mirror (docker run -p 5000:5000 registry). Organizers
>> could run this at large events and configuring docker to use a local 
>> mirror
>> on the network is a one-line change for atendees.
>>
>>
>>
>>
>> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com)
>> wrote:
>>
>> Size of the image could definitely be a concern, especially at
>> sprints where wifi speeds aren't always optimal. The django-box image is
>> significantly larger though so it'd still be a net win. There are also
>> optimisations that can be made to the image for reducing size over time, 
>> so
>> I'd fully expect it to come down. I've spent a little bit of time trying 
>> to
>> optimise a $work$ python docker file, I'll provide what I've got as an
>> issue to possibly look at.
>>
>> I see that the ticket has been accepted and I think that's a great
>> step forward. I'd also like to hear from the infrastructure team what 
>> their
>> thoughts on using docker over customised build environments would be.
>>
>> Florian, Tim, Markus .. any thoughts? (Apologies, I've missed some,
>> this list of names is from memory).
>>
>> On Wednesday, 5 December 2018 10:39:16 UTC+11, Tom Forbes wrote:
>>>
>>> Thank you for the reply Josh. I didn’t anticipate any suggestions
>>> for including this inside core but off the back of your suggestion I’ve
>>> made a ticket here: https://code.djangoproject.com/ticket/30010.
>>>
>>> I don’t think it should be complex at all to include this inside
>>> Django - it’s four or five new files at most. Hopefully this should 
>>> improve
>>> the experience at sprints, however the current Dockerfile weighs in at
>>> 650+mb so the problem may switch from ‘it is hard to set up an 
>>> en

Re: Python version support for LTS Django (in particular v2.2)

[Jani Tiainen]

Problem is that Python.org site always gives latest version as default
download.

When 3.8 was released one lib I work with suddenly got flood of help
requests because there was not prebuilt packages for 3.8.

So I think it's more issue for people that inadvertly upgrades Python.

to 31. lokak. 2019 klo 11.39 Johannes Hoppe 
kirjoitti:

> I am trying to understand the motivation to use an "old" Django 2.2 but a
> "bleading edge" Python version. I can understand Nicks logic of people
> needing to upgrade form Python 2 to 3 and Debian by default gave them
> Python 3.7.
> Following that narrative, maybe we should check what the major operating
> systems have in stall for us, right? Then again, there is not going to be a
> big Python 2 to 3 change again *fingerscrossed*.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/be847bcd-fff5-4672-8d1e-775d8fa7b429%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91of%2B3oDEyb6cHcKtPG3gk61%3DucqpoRzUnPRpZ%2BS7ux2ZSg%40mail.gmail.com.

Re: [GSoC 2016]Proposal: Validity check at client and dynamic form framework

[Jani Tiainen]

On 20.03.2016 14:59, Lover Di wrote:

Hi,

I have been working for preparing a proposal about a new feature for 
Django. I'm posting my draft proposal to Gist and want to know my idea 
is OK or not. So I can proceed with the right approach. Any 
suggestions or advice are welcome.


Abstract of my proposal:

  * Automatically generate some simple javascript code to check the
validity for forms
  * Many dynamic forms use similar logic, they can be abstracted into
a framework to help generated view code and javascript code, users
only need to fill out the logic of "how to change". Thus, the
workload of write dynamic form greatly reduced.


Proposal URL: https://gist.github.com/7sDream/46de98da073b9021c5d0


Hi,

Your proposal does have few points that I would like to address so you 
could make your proposal more solid:


 - What changes are required in Django core/forms to make this work? By 
looking your current proposal it looks like something that can be done 
without any changes to Django core/forms. This is actually your 
"homework" that you have to do for proposal.


 - You propose that this could be "django.contrib" package.That gives a 
hint that this could be a 3rd party package. So it would be beneficial 
that you actually do some reference implementation for example for few 
fields to backup your proposal. If this requires some changes to core, 
you can point them out in your proposal much easier.


 - Django has a tradition to be agnostic from client side JS 
frameworks. Your proposition states that validation would use jQuery. 
What if I want to use something else like Dojotoolkit or ExtJS (which I 
do use, I don't use jQuery at all).


 - In your proposal Javascript is generated in a Python. It's generally 
considered already a bad thing that forms makes certain rendering 
designs HTML. Your proposal is to move more representation parts into 
Python side. Could some of it be moved to presentation layer (templates)?


--

Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56F1393A.1000504%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Oracle backend and passing data as is.

[Jani Tiainen]

I'm toying around Oracle and latest cx_Oracle feature that allows 
putting real objects through cx_Oracle to database. One use case is GIS 
which is way faster than trying to transfer WKT over queries.


I just have one problem - how I can tell in the backend that one 
particular query parameter and it's must be kept as is, and it's type 
set automatically (or not to set at all on Django side).


Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got 
NCHAR" error.


--

Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573B143B.5050400%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle backend and passing data as is.

[Jani Tiainen]

Unfortunately problem seem to lie somewhere in standard Oracle backend 
and it's way to handle arguments and argument types. Most probably it's 
FormatStylePlaceholderCursor object that does it.


On 18.05.2016 00:09, Claude Paroz wrote:

Hello Jani,

I'm not familiar with the Oracle backend, but you probably have to 
play with the
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. Good 
luck!


Claude

Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :

I'm toying around Oracle and latest cx_Oracle feature that allows
putting real objects through cx_Oracle to database. One use case
is GIS
which is way faster than trying to transfer WKT over queries.

I just have one problem - how I can tell in the backend that one
particular query parameter and it's must be kept as is, and it's type
set automatically (or not to set at all on Django side).

Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got
    NCHAR" error.

-- 


Jani Tiainen

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1da65293-721c-4790-ae76-b146d580d22d%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/1da65293-721c-4790-ae76-b146d580d22d%40googlegroups.com?utm_medium=email&utm_source=footer>.

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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573BF445.2070109%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle backend and passing data as is.

[Jani Tiainen]

Hm.

I was able to figure out what it was and do have hack around that. 
OracleParam class does certain checks, mainly it chekcs if param is 
date/time/timedelta or true/false. Otherwise it converts everything to 
string.


And that's where backend thinks that WKTAdapter coming from Oracle GIS 
backend is actually a string and runs some conversion.


So instead of that I should be able to say "raw value, don't touch". 
Only way I managed to do it currently was to introduce "bind_parameter" 
method on my WKTAdapter which just returns raw object.


This solution works but it feels a bit of wrong since I guess bind 
parameter isn't exactly meant for that.



On 18.05.2016 10:54, Aymeric Augustin wrote:
Yes, we have a lot of code in this area. It isn’t particularly 
complex, but it isn’t always easy to tell what problem a particular 
line of code solves either. I’m afraid “educated guesses” are your 
best option at this point.


Conditionally skipping some type conversions on sufficiently modern 
cx_Oracle / Oracle versions would be nice :-)


--
Aymeric.

On 18 May 2016, at 06:49, Jani Tiainen <mailto:rede...@gmail.com>> wrote:


Unfortunately problem seem to lie somewhere in standard Oracle 
backend and it's way to handle arguments and argument types. Most 
probably it's FormatStylePlaceholderCursor object that does it.


On 18.05.2016 00:09, Claude Paroz wrote:

Hello Jani,

I'm not familiar with the Oracle backend, but you probably have to 
play with the
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. 
Good luck!


Claude

Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :

I'm toying around Oracle and latest cx_Oracle feature that allows
putting real objects through cx_Oracle to database. One use case
is GIS
which is way faster than trying to transfer WKT over queries.

I just have one problem - how I can tell in the backend that one
particular query parameter and it's must be kept as is, and it's
type
set automatically (or not to set at all on Django side).

Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got
NCHAR" error.

-- 


Jani Tiainen

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1da65293-721c-4790-ae76-b146d580d22d%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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573BF445.2070109%40gmail.com 
<https://groups.google.com/d/msgid/django-developers/573BF445.2070109%40gmail.com?utm_medium=email&utm_source=footer>.

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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/AFBAE5CE-64B2-4CBA-B254-3E39B84FA7AB%40polytechnique.org 
<https://groups.google.com/d/msgid/django-developers/AFBAE5CE-64B2-4CBA-B254-3E39B84FA7AB%40polytechnique.org?utm_medium=email&utm_source=footer>.

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 

Re: Google Summer of Code Updates - Class based indexes

[Jani Tiainen]

fd50505928dac58dc350e6cb186a404

<https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404>
for the timeline.

On Monday, June 27, 2016 at 5:02:06 PM UTC-4,
thinkwel...@gmail.com wrote:

Will it be possible to create indexes other
than btree? In reviewing the code it doesn't
look like it but I hope I'm wrong. It'd be
awesome to support the many more specific
index options without using run_sql.

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/be05e9f0-ed44-4c73-aa41-b02349584e29%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/be05e9f0-ed44-4c73-aa41-b02349584e29%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/579746BE.9080803%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

[Jani Tiainen]

;pEnd',html,time=None,end=True)

else:
ifcompress == False:
ifdecompressor == False:
decompressor = 
zlib.decompressobj(wbits=self.wbits)

html = decompressor.decompress(zData)
zPage += zData
cache.set(pageKey, zPage, expire)
self.newtime = time.perf_counter()
ifcompress == False:
zData = html
yieldzData
else:
ifcompress == False:
ifdecompressor == False:
decompressor = zlib.decompressobj(wbits=self.wbits)
zPageData = decompressor.decompress(zPageData)
yieldzPageData

classFastView(ZipView):

c = connection.cursor()

defget(self, request):
returnself.html(request)

defhtml(self, request, slug=None):
try:
encoding = request.META['HTTP_ACCEPT_ENCODING']
except:
encoding = ''
if'gzip'inencoding:
compress = True
else:
compress = False
ifsettings.BENCHMARK:
count = 1
logger.info <http://logger.info>('//Starting Benchmark')
logger.info <http://logger.info>(' Class name: %s'% 
self.__class__.__name__)

start_time = timing = time.perf_counter()
ifcompress:
page = b''
forhtml inself.generator(request,slug,compress):
page += html
newtime = time.perf_counter()
logger.info <http://logger.info>('  Step %i: %fms'% (count, 
(newtime-timing)*1000))

count = count + 1
timing = newtime
logger.info <http://logger.info>(' Total Time: %fms'% 
((newtime-start_time)*1000))

logger.info <http://logger.info>('//End Benchmark')
response = HttpResponse(page)
ifcompress:
response['content-encoding'] = 'gzip'
returnresponse
else:
response = 
StreamingHttpResponse(self.generator(request,slug,compress))

ifcompress:
response['content-encoding'] = 'gzip'
returnresponse

classIndexView(FastView,factory):

title = 'FutureClaw'

@staticmethod
defgetPageKey(slug=None):
return'pIndex'

deffragments(self,request=None,slug=None):
return[

['pMetaIndex','',3600,self.get_page_meta_stream,self.title, None, None],

['pCover','',3600*24,self.get_cover_page_stream,self.c],

['pStartCategory','',None,self.get_start_category_page_stream],

['pHeadlines','',3600,self.get_headlines_stream,self.c],
['pLatest','',3600,self.get_latest_collection_stream,self.c],

['pFullSeasonStart','',None,self.get_full_season_start_stream],

['pFullSeason',None,3600,self.get_full_season_stream,None,None],

['pAllSeasons',0,3600*72,self.get_all_seasons_stream,self.c,0,''],

['pGallery',0,None,self.get_gallery_stream,None,None,None,None],

['pArticle',0,None,self.get_article_stream,None],
]

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5B4D7D1E-F21B-4CA0-AABD-95610A8DAF40%40gmail.com 
<https://groups.google.com/d/msgid/django-developers/5B4D7D1E-F21B-4CA0-AABD-95610A8DAF40%40gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

--

Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c07faa64-875d-09ed-9c45-d9dad781e40c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add past/present/future validations for Date and DateTime types

[Jani Tiainen]

Hi,

As Tim pointed out this can easily live as an external package.

Also you have to be really careful with dates and specially datetimes 
when playing with timezones and daylight saving time. Specially since 
you mention that invoice dates that may belong to past/present/future.



On 30.08.2016 23:16, 'Mariano Baragiola' via Django developers 
(Contributions to Django itself) wrote:

Hello django-developers@,

On more than one project, I find myself implementing the same feature over
and over again. It's not a rare case scenario, for instance: it's common
that invoices have a date that belongs to the past or the present 
time, but

not the future.

Seeing that we have django.core.validators.MinValueValidator and
django.core.validators.MaxValueValidator, I propose the following:

* django.core.validators.DateIsPresent
* django.core.validators.DateIsPresentOrPast
* django.core.validators.DateIsPresentOrFuture
* django.core.validators.DateIsFuture

This way, one may easily use them at models.py just like MinValueValidator
and MaxValueValidator.

The code would be really simple, I have them -differently- implemented at:
https://github.com/heimdalerp/heimdalerp/blob/master/common/validators.py

Please, let me know if there's already an easier way to do this with
current Django, or if this belongs to a custom app instead.

If it is ok to add this feature to Django, I can gladly take care of it.

Thanks in advance. --
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D6FE121C-FCA4-422C-8AF6-1E5BD87B091A%40yahoo.com 
<https://groups.google.com/d/msgid/django-developers/D6FE121C-FCA4-422C-8AF6-1E5BD87B091A%40yahoo.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7782af37-c196-68d9-1ae9-1e51f6157272%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ending support for Oracle 11.2?

[Jani Tiainen]

My vote would be +1 for dropping support for 11.2 after Django 1.11 
since it would fit quite nicely on schedule of Oracle extended support.


What comes to those listed issues I think they should work on all 
supported versions (it's still ~3 years until 11.2 is decommissioned).


SRIDs are something that may cause troubles but that's more like a thing 
that Oracle GeoDjango user should know what to use and how to handle it 
so I wouldn't worry too much about them.


On 22.12.2016 14:48, Tim Graham wrote:
Oracle's extended support for 11.2 ends Dec 2020. We don't currently 
have testing on the CI servers for 11.2, and I think the Developer 
Days VM for 11.2 is no longer available from Oracle (I have a local 
copy that I've used for testing). Making the GIS tests work on Oracle 
11.2 and Oracle 12 is causing some non-trivial work, so I wanted to 
ask if it's worthwhile.


Perhaps dropping 11.2 support after Django 1.11 would be okay. Django 
1.11 will be supported until April 2020 which almost reaches Oracle's 
Dec 2020 date.


https://github.com/django/django/pull/7704 - Removed unneeded Oracle 
workaround in GISFunctionsTests.test_num_points (doesn't work on 11.2)
https://github.com/django/django/pull/7672 - Some back and forth was 
needed here to find an SRID that works on Oracle 11.2 and 12
https://github.com/django/django/pull/7695#discussion_r92675976 - Two 
existing GIS test failures with Oracle 11.2

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/63bf1889-5fd1-4415-82c1-856172c140c2%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/63bf1889-5fd1-4415-82c1-856172c140c2%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ed1d36b-17e3-21d0-9347-d0bc36d6ad82%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: draft blog post for Oracle help

[Jani Tiainen]

Just a note - Oracle announced few days ago official 12c docker images 
available (for free) from docker store. So there is now alternative way 
to have oracle database for testing.


See https://github.com/oracle/docker-images/tree/master/OracleDatabase 
for scripts and


https://store.docker.com/images/oracle-database-enterprise-edition?tab=description


On 04.05.2017 22:02, Mariusz Felisiak wrote:

I updated https://code.djangoproject.com/wiki/OracleTestSetup instruction.
--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/657b52aa-6e42-4d77-90ab-644f894ce205%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/657b52aa-6e42-4d77-90ab-644f894ce205%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cbcf303b-4dc2-23d4-f110-a3e829178a0c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Are there use cases for storing null bytes in CharField/TextField?

[Jani Tiainen]

Hi,

I would guess that one could use null byte to denote "empty field" in 
Oracle for example. (I recall seeing such a convention in one of our 
non-django apps). And that's to overcome limitation that Oracle doesn't 
have real concept of empty string so we stored single null byte to mark 
that.




On 15.05.2017 18:54, Tim Graham wrote:
Does anyone know of a use case for using null bytes in 
CharField/TextField?


psycopg2 2.7+ raises ValueError("A string literal cannot contain NUL 
(0x00) characters.") when trying to save null bytes [0] and this 
exception is unhandled in Django which allow malicious form 
submissions to crash [1]. With psycopg2 < 2.7, there is no exception 
and null bytes are silently truncated by PostgreSQL. Other databases 
that I tested (SQLite, MySQL, Oracle) allow saving null bytes. This 
creates possible cross-database compatibility problems when moving 
data from those databases to PostgreSQL, e.g.[2].


I propose to have CharField and TextField strip null bytes from the 
value either a) only on PostgreSQL or b) on all databases. Please 
indicate your preference or suggest another solution.


[0] https://github.com/psycopg/psycopg2/issues/420
[1] https://code.djangoproject.com/ticket/28201 - Saving a 
Char/TextField with psycopg2 2.7+ raises ValueError: A string literal 
cannot contain NUL (0x00) characters is unhandled
[2] https://code.djangoproject.com/ticket/28117 - loaddata raises 
ValueError with psycopg2 backend when data contains null bytes

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/22fac845-6870-de4e-6fbe-eab247b8853a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.