date:20160518

Re: Oracle backend and passing data as is.

2016-05-18 Thread Aymeric Augustin

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  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 
>> .
>> 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/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 
> .
> 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 
> .

-- 
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/AFBAE5CE-64B2-4CBA-B254-3E39B84FA7AB%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle backend and passing data as is.

2016-05-18 Thread 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 > 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

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.

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.

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
.

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

Re: SPAM Re: Middleware+Transactions:

2016-05-18 Thread Florian Apolloner

Starting with Django 1.10 you can write a TransactionMiddleware again, and 
we will probably ship one again.

On Tuesday, May 10, 2016 at 2:07:30 AM UTC+2, Kevin Tran wrote:
>
> Thomas, did you ever find a solution to your problem?  I'm having similar 
> thoughts and am looking for an answer.
>
> On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>>
>>
>>
>> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen: 
>> > I'd really like to be able to define middlewares that actually work in 
>> > a well defined and easy to use way. Currently, there is no 
>> > guarantee(!) that either process_exception or process_response gets 
>> > called after process_request has been called for given middleware, and 
>> > this makes it impossible to implement a transaction middleware purely 
>> > as a middleware. 
>>
>> It's the same with TestCase.setUp() and TestCase.tearDown() does not work 
>> well together with decorators. 
>>
>> You are right. Instead of 
>>
>>   settings.MIDDLEWARES_INSIDE_TRANSACTION 
>>
>>   settings.CONTEXT_MANAGERS 
>>
>> would be better. 
>>
>> The atomic() could be one entry in the list of context managers. 
>>
>> > An idea... Would investigating and implementing better middlewares (or 
>> > urlpattern wrappers) make for a good GSoC project? Maybe the "wrap 
>> > URLs" approach could be part of the URL resolve refactoring GSoC 
>> > project? 
>>
>> I don't know if GSoC is a good solution. It is appealing, since 
>> it looks that someone else does the work (not me and my team mates). 
>> But I am a little bit afraid that will this result in a more complicated 
>> implementation. My perfect solution are only very few lines of code. 
>> I guess this could be possible. I guess the diff for the docs 
>> could be longer then the diff for the code. 
>>
>> Regards, 
>>Thomas 
>>
>> -- 
>> Thomas Güttler 
>> http://thomas-guettler.de/ 
>>
>

-- 
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/9497008a-ddfd-41ca-86be-0ab734e31c56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SPAM Re: Middleware+Transactions:

2016-05-18 Thread charettes

As MIDDLEWARE supports decorator-like objects you could simply add 
`django.db.transaction.atomic' to it and you'd get each request wrapped in 
a transaction.

Note that this will only start a transaction on the `default` database, 
just like the old TransactionMiddleware use to do.

Simon

Le mercredi 18 mai 2016 06:14:04 UTC-4, Florian Apolloner a écrit :
>
> Starting with Django 1.10 you can write a TransactionMiddleware again, and 
> we will probably ship one again.
>
> On Tuesday, May 10, 2016 at 2:07:30 AM UTC+2, Kevin Tran wrote:
>>
>> Thomas, did you ever find a solution to your problem?  I'm having similar 
>> thoughts and am looking for an answer.
>>
>> On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>>>
>>>
>>>
>>> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen: 
>>> > I'd really like to be able to define middlewares that actually work in 
>>> > a well defined and easy to use way. Currently, there is no 
>>> > guarantee(!) that either process_exception or process_response gets 
>>> > called after process_request has been called for given middleware, and 
>>> > this makes it impossible to implement a transaction middleware purely 
>>> > as a middleware. 
>>>
>>> It's the same with TestCase.setUp() and TestCase.tearDown() does not 
>>> work 
>>> well together with decorators. 
>>>
>>> You are right. Instead of 
>>>
>>>   settings.MIDDLEWARES_INSIDE_TRANSACTION 
>>>
>>>   settings.CONTEXT_MANAGERS 
>>>
>>> would be better. 
>>>
>>> The atomic() could be one entry in the list of context managers. 
>>>
>>> > An idea... Would investigating and implementing better middlewares (or 
>>> > urlpattern wrappers) make for a good GSoC project? Maybe the "wrap 
>>> > URLs" approach could be part of the URL resolve refactoring GSoC 
>>> > project? 
>>>
>>> I don't know if GSoC is a good solution. It is appealing, since 
>>> it looks that someone else does the work (not me and my team mates). 
>>> But I am a little bit afraid that will this result in a more complicated 
>>> implementation. My perfect solution are only very few lines of code. 
>>> I guess this could be possible. I guess the diff for the docs 
>>> could be longer then the diff for the code. 
>>>
>>> Regards, 
>>>Thomas 
>>>
>>> -- 
>>> Thomas Güttler 
>>> http://thomas-guettler.de/ 
>>>
>>

-- 
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/3602ab24-40a9-4ab6-b5f4-ffd5b52872af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

2016-05-18 Thread Tim Graham

A couple issues remain before the alpha release:

Issue: Fixing some new-style SessionMiddleware to process the response even 
if the view raises an exception.
Status: This is somewhat in design decision needed if anyone would like to 
take a look and offer feedback. I'll look at it more closely tomorrow.
https://github.com/django/django/pull/6618

Issue: Made CSRF tokens change every request.
Status: Awaiting final (trivial, I believe) updates from Shai.
https://github.com/django/django/pull/5605

Issue: i18n test failures on Windows
Status: Awaiting someone with interest in Windows i18n to investigate. I'm 
not considering this a blocker for the release (alpha or otherwise) since 
we can't guarantee sometime with Windows expertise to fix the issue.
https://code.djangoproject.com/ticket/25677

I hope to resolve these issues and make the alpha release tomorrow or 
Friday.

On Saturday, May 14, 2016 at 7:40:32 PM UTC-4, Tim Graham wrote:
>
> Time to kickoff the progress tracker for the next major release!
>
> At this time, I'm considering master feature frozen besides the tickets 
> marked "ready for checkin" [1] and those tagged "1.10" [2]. Let me know if 
> I missed anything critical.
>
> I'll continue working with the ticket owners to polish those patches. I'll 
> also continue merging bug fixes until we create the stable/1.10 branch and 
> issue the alpha release, which I'd like to do sometime next week.
>
> [1] 
> https://code.djangoproject.com/query?status=assigned&status=new&stage=Ready+for+checkin&col=id&col=summary&col=status&col=owner&col=type&col=version&order=priority
> [2] 
> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.10&stage=Accepted&col=id&col=summary&col=status&col=owner&col=type&col=version&col=changetime&desc=1&order=changetime
>

-- 
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/311634c5-e4cf-48ba-b2c3-91ac40c3ce8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

2016-05-18 Thread Jon Dufresne

Hi,

Occasionally I'll need to define a CharField on a model that is unique but
also allow blank values. At the database level, this is easily handled by
storing NULL for the blank values. (Storing the empty string multiple times
will result in a DB unique constraint violation.) This use case has
surfaced several times as evident by the 9 year old ticket #4136 [1].

I have created a POC solution to the ticket at PR 6624 [2]. The change adds
the attribute "empty_value" to forms.CharField. The value specified by
empty_value is used as the Python empty value for the field. This value
defaults to the empty string (current behavior) but could also be changed
to None. The change also modifies model forms to set empty_value to None
for CharField when null=True is set. The model forms change allows the use
of the admin to save blank, unique char values without unique constraint
violations.

This choice to create the empty_value attribute API was based on the prior
art of the empty_value attribute of TypedChoiceField [3].

In the PR Tim Graham requested I raise the new API on the developers list.
I'm looking for concerns or feedback regarding the new attribute or any
other issue with the PR.

Thanks!

Cheers,
Jon

[1] https://code.djangoproject.com/ticket/4136
[2] https://github.com/django/django/pull/6624
[3]
https://github.com/django/django/blob/218175b/django/forms/fields.py#L832-L856

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

Organizing the built-in system check framework's hint messages

2016-05-18 Thread Quentin Fulsher

Hi all,

Recently I was trying to fix a bug that required me to alter the hint
message of the `fields.E306`[1] system check error[2]. The bug in question
added a condition to a check which if failed caused the instantiation of a
`django.core.checks.Error` object. In order to change the `Error`'s hint
properly I would have to change the hint in 3 different places. Once where
the `Error` was instantiated, in the documentation, and in it's tester.
This was a rather tedious task and if done improperly can lead to differing
error messages. Rather than just passing the hint in as an argument to the
constructor I think it would be better if the Error object had the option
to lookup it's error messages rather than just having them given.

It wouldn't take much effort to create a dictionary of `id: message` pairs
which `Error` objects could use to lookup their messages/hints. In the
event that an `Error` is instantiated with no hint/message given it could
perform a quick check to see if it is logged in the dictionary. This would
not add any significant overhead to the process and eliminate some
possibility of human error.

This situation becomes even more tedious if you have more than one place
where the error is instantiated or tested. This could also help with
documentation because all of the builtin error messages would be stored in
a central location.

In any case, let me know what you guys think. I know its kind of a
non-issue as the current system works fine. I just thought there was some
room for improvement. Thanks!

[1] https://docs.djangoproject.com/en/1.9/ref/checks/#fields
[2] https://docs.djangoproject.com/en/1.9/topics/checks/

--
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/07d224fa-4b73-4450-97f2-3c0a2214ea36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle backend and passing data as is.

Re: Oracle backend and passing data as is.

Re: SPAM Re: Middleware+Transactions:

Re: SPAM Re: Middleware+Transactions:

Re: status of 1.10 release blockers

New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

Organizing the built-in system check framework's hint messages

7 matches

Site Navigation

Mail list logo

Footer information

Re: Oracle backend and passing data as is.

Re: Oracle backend and passing data as is.

Re: ***SPAM*** Re: Middleware+Transactions:

Re: ***SPAM*** Re: Middleware+Transactions:

Re: status of 1.10 release blockers

New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

Organizing the built-in system check framework's hint messages

7 matches

Mail list logo

Re: SPAM Re: Middleware+Transactions:

Re: SPAM Re: Middleware+Transactions: