Part of the reason to use Django is to assure some level of database
portability. I use Oracle exclusively at work, although there are some
plans to move towards PostgreSQL. I think blank=True should govern whether
the field may be null or not.
So, from my perspective, we should limit ourselves
I created a ticket and a pull request to add sqlparse as a required
dependency.
https://code.djangoproject.com/ticket/29934
https://github.com/django/django/pull/10622
On Saturday, November 3, 2018 at 4:47:30 PM UTC-4, charettes wrote:
>
> > So you want to add it to Django's install_requires
Hi,
Oracle treats empty strings and NULLs in the same way, that's why we
had to decide on some workaround that will cover both python's (other Dbs')
cases i.e. NULLs and "" (see
https://docs.djangoproject.com/en/2.1/ref/databases/#null-and-empty-strings).
I don't see much value in
Hi Florian,
Yes you are correct, backwards compatibility would break with this change.
As Django already mimics the required checks in middleware for nulls, only
difference I can see going forward would be that newly inserted blank
strings would be read back back as None, instead of '' if
Hi Vackar,
Thank you, now we are getting somewhere!
On Thursday, November 8, 2018 at 5:36:53 PM UTC+1, vaf...@exscientia.co.uk
wrote:
>
> My main concern currently is that required fields are not enforced at the
> db level, which makes using it with other clients difficult. I would much
>
Vaclav,
With your approach, fields are correctly created with / without null
constraints based on the value of the 'null' parameter.
However subsequent changes are not being picked up by the migrations
framework. i.e. if I change null=True to null=False, constraint is not
dropped. The same is
Hi Florian
No probs, most people don't understand Oracle, it's a bit of a black art.
Some background: Partly for legacy and partly for justifiable reasons,
oracle converts blank strings to null.
Back to this issue, as you say, if you implemented the above
recommendations you would not be able
On Thursday, November 8, 2018 at 3:52:01 PM UTC+1, vaf...@exscientia.co.uk
wrote:
>
> - If null=False is specified, then add an explicit not null constraint at
> the db level
>
As far as I understand Oracle makes no difference between null and an empty
string. So if we were to add a not-null
Vaclav, this is an interesting approach. I know it's a very simple field,
but have you though of creating an open source package for this, looks
really useful.
Would probably call it RequiredCharField though, the double negative in
NonEmptyCharField can make it a slightly harder to read.
On
Hi Florian,
Thanks for getting back to me. Allow me elaborate
My main question is: what is the rationale for enforcing null value checks
in middleware, and not delegating to DB?
My proposal would be:
- If null=False is specified, then add an explicit not null constraint at
the db level
- When
While it is probably not possible to change how Django treats this, many
newcomers find it super confusing. To make developer experience in our
Oracle-based project better, we started using the following workaround for
fields which are required to be not null and not empty string:
class
Oracle treats NULL and empty varchar2 the same; so null=True/False is
simply not possible on Oracle for CharField. I am not sure what you are
proposing here…
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
Dear Django Team,
CharField on an Oracle backend has some strange behaviour. Because oracle
treats empty strings and nulls in a similar fashion, Django simply ignore
the null parameter (which should control nullability) on the field.
I agree that an empty string and a null value are under most
Dear Django Team,
The current behaviour of Django with an Oracle backend is to ignore the
null parameter on CharFields. The implication of this is that all text
fields are effectively optional, with the justification being that Oracle
treats nulls and empty strings in a similar manner. I don't
OK, makes sense.
My current thinking is to Accept both. Perhaps you could put docs changes
you'd make in a third PR (or ticket if you like, to discuss the outline)?
(Maybe one PR with three commits makes it easier to review as a whole.)
Thanks for the input!
On Thursday, 8 November 2018
On 08/11/2018 11:43, Carlton Gibson wrote:
> My only concern thus far is bringing out the change well enough in the
> release notes and docs.
> (Split between the two PRs I'm not sure it quite does that.)
My impression is that authentication backends and object permissions
have already been
Hi Peter,
Thanks for the follow-up here. For me, optional field-level encryption
would be a cool addition.
Can I solicit some opinions:
* Do we think this would merit a place in `contrib.postgres` (vs the
third-party package)?
* Postgres buffs: any comment on the actual implementation?
Hi Tobias,
Thank you for your effort here. Sorry for the slowish response: it's just a
question of getting round to it.
The basic issue here is people what to avoid this:
if user.has_perm('foo.change_bar', obj=bar) or
user.has_perm('foo.change_bar'):
...
(Or they find it
Hi,
On Thursday, November 8, 2018 at 8:12:51 AM UTC+1, Alex Toussaint wrote:
>
> The attacker can have access to the password hash but no longer to the
> last login. if that same attacker is exploiting a vulnerability that gets
> patched just after (ex. Heartbleed) or has view on past data (ex.
19 matches
Mail list logo
