date:20160518

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.

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: 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: 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: 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: SPAM Re: Middleware+Transactions:

2016-05-18 Thread guettli



Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran:
>
> Thomas, did you ever find a solution to your problem?  I'm having similar 
> thoughts and am looking for an answer.
>
>

Carl Meyer has worked out an enhancement proposal, here is the 
pull-request: https://github.com/django/django/pull/6501


-- 
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/85e8ea1f-a9af-42fa-81e3-c218d217d9e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

2016-05-18 Thread Carl Meyer

On 05/17/2016 01:33 AM, Claude Paroz wrote:
> I can imagine that django.forms would then be responsible to tell the
> template engine to add the template source. Maybe this would need a new
> API in the template code?

Yes, it's certainly possible that we could address this with a new API
in the template engines. That's a more significant change than I had
thought we needed, but it may be the best option.

I'm happy to work on this issue more, but it's not likely to be until
the PyCon sprints.

Carl



-- 
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/573C1083.8030304%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Template-based widget rendering

2016-05-18 Thread Carl Meyer

Hi Simon,

On 05/17/2016 07:28 AM, charettes wrote:
> Did we consider defining a template loader that knows where to load the
> widget
> templates from instead of requiring 'django.forms' in INSTALLED_APPS with
> 'APP_DIRS': True in TEMPLATES?
> 
> Something along theese lines make more sense to me:
> 
> TEMPLATES = {
> {  
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'DIRS': [],
> 'APP_DIRS': True,
> 'OPTIONS': {
> 'loaders': [
> 'django.forms.templates.loader.WidgetTemplateLoader',
> ]
> },
> },
> }

I think the solution needs to be at a higher level than DTL loaders,
because it should work also for Jinja2.

And this approach doesn't really help solve the backwards-compatibility
path, unless we'd automatically insert such a loader if it's not listed
explicitly.

Carl

-- 
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/573C0FF5.5040801%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

Re: SPAM Re: Middleware+Transactions:

Re: SPAM Re: Middleware+Transactions:

Re: Oracle backend and passing data as is.

Re: Oracle backend and passing data as is.

Re: SPAM Re: Middleware+Transactions:

Re: Template-based widget rendering

Re: Template-based widget rendering

8 matches

Site Navigation

Mail list logo

Footer information