Re: [Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by akaariai):

 After little confusion I managed to backpatch the patches... I imagined I
 could cherry-pick the merge, but it seems that isn't possible... So, I
 cherry picked the individual commits instead.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"908efca81723af7a3f4fb5b586e530ed7cd3952b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="908efca81723af7a3f4fb5b586e530ed7cd3952b"
 Fixed #19198 -- merged 4 different Oracle fixes
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 Aand... Actually marking as RFC.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Two more failures:
   - Some gis tests try to run on default oracle. The test skipping checks
 only if the backend is 'oracle', not if it is gis enabled Oracle.
   - Inspectdb failure where Oracle reports twice the length for character
 columns. This is reported in #17202 as a separate issue.

 I have implemented as-simple-as-possible fixes for the above cases. The
 fixes are:
   - Check that 'gis' is in the backend engine if the engine is Oracle
   - Mark the test as expected failure on Oracle

 I am marking this as ready for commit. The patch-series is available from
 https://github.com/akaariai/django/compare/fix_oracle2

 All patches need to be backported. The only severe issue is the
 select_related case, but this isn't present in 1.5a1.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by akaariai:

Old description:

> Two Oracle specific failures have been introduced lately:
>   - Inability to deal with "%" in table or other identifier names
> (present in 1.5a1)
>   - Oracle not working correctly for select_related cases where the
> related model is null but contains character fields (master only)
>
> The first of the failures happens because Oracle backend does querystr %
> args formatting and if a table name contains '%' then the formatting will
> fail.
>
> The second one happens because we check for if all fetched columns are
> None then set related object to None in models/query.py when creating the
> related objects. Due to a recent change we correctly convert the row
> values in compiler.py for related select fields, too. This means that
> None values will be converted to '' and the check in models/query.py
> fails.
>
> Draft patches available from:
> https://github.com/akaariai/django/compare/fix_oracle2

New description:

 Two Oracle specific failures have been introduced lately:
   - Inability to deal with "%" in table or other identifier names (present
 in 1.5a1)
   - Oracle not working correctly for select_related cases where the
 related model is null but contains character fields (master only)

 The first of the failures happens because Oracle backend does querystr %
 args formatting and if a table name contains '%' then the formatting will
 fail.

 The second one happens because we check for if all fetched columns are
 None then set related object to None in models/query.py when creating the
 related objects. Due to a recent change we correctly convert the row
 values in compiler.py for related select fields, too. This means that None
 values will be converted to "" and the check in models/query.py fails.

 Draft patches available from:
 https://github.com/akaariai/django/compare/fix_oracle2

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19198: Oracle specific failures

[Django]

#19198: Oracle specific failures
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.5-alpha-1
  layer (models, ORM)|   Keywords:  oracle
   Severity:  Normal |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Two Oracle specific failures have been introduced lately:
   - Inability to deal with "%" in table or other identifier names (present
 in 1.5a1)
   - Oracle not working correctly for select_related cases where the
 related model is null but contains character fields (master only)

 The first of the failures happens because Oracle backend does querystr %
 args formatting and if a table name contains '%' then the formatting will
 fail.

 The second one happens because we check for if all fetched columns are
 None then set related object to None in models/query.py when creating the
 related objects. Due to a recent change we correctly convert the row
 values in compiler.py for related select fields, too. This means that None
 values will be converted to '' and the check in models/query.py fails.

 Draft patches available from:
 https://github.com/akaariai/django/compare/fix_oracle2

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.