I believe there are a bunch of similarities between the requirements of
generated fields and my project
django-shared-property: https://django-shared-property.readthedocs.io/en/latest/
On Sunday, December 25, 2022 at 10:23:10 AM UTC+10:30 jeremy...@gmail.com
wrote:
> I'd love to help implement
//docs.microsoft.com/en-us/sql/t-sql/queries/select-transact-sql?redirectedfrom=MSDN&view=sql-server-ver15#logical-processing-order-of-the-select-statement
>
> Luke
>
>
> On 28/07/2021 05:02, Matthew Schinckel wrote:
>
> Greetings,
>
> For a couple of things I’ve been wor
ub.com/schinckel/django-shared-property
<https://github.com/schinckel/django-shared-property> - which is woefully
under-documented, but basically allows defining an expression as something that
should (a) always be annotated onto a query, but (b) also be “live”, and
changes to the depende
h I'm keen to revisit it,
actually), but it's actually possible that we can do it without any changes
to Django.
https://github.com/schinckel/django-shared-property
Matt.
On Sunday, March 14, 2021 at 11:46:15 PM UTC+10:30 Tobias Bengfort wrote:
> Hi,
>
> a while back ther
Great work on this, Alexandr. I've been thinking a lot about doing joins in
Django to subqueries. As you point out, when you are doing several subquery
annotations of the same subquery, just with different columns, that can
really hurt performance. Currently, I've been recommending doing a JSON
On Wednesday, March 25, 2020 at 1:45:48 AM UTC+10:30, Petr Přikryl wrote:
>
> Hi Adam,
> thank you for your reply.
>
> We usually have few indices, functions and triggers. But the most used
> database object is view. We used them for data synchronizing from some
> third party databases. These d
Hi Ole,
I'm interested in what you are trying to do with JSONExtract. I have a
subclass of Func called JSONBExtractPathText that I use with great success
to extract parts of a JSONB object.
Also, as of Django 3.0, you can filter directly on an expression (that has
an output_field of BooleanFie
I started some work late last night on attempting to replace some RawSQL()
calls that do a sub query with a new Expression.
It actually worked!
Even in the cold light of day, it doesn't seem _too_ bad, so after working
on it a bit today with jarshwah, I decided to stick up a WIP PR.
https://gi
That's the approach I've used: either have a migration operation that you
can run (included in a 3rd party or local app), or a management command
that generates a migration file with the relevant custom operations.
Matt.
On Friday, August 28, 2015 at 11:37:55 AM UTC+9:30, Andrew Godwin wrote:
>
As it turns out, this is the approach I've settled on for my Postgres
Composite Type/Field implementation.
https://bitbucket.org/schinckel/django-postgres/src/6a6078d8a2cc30bfb61d093354b8228f76484a0c/postgres/fields/composite_field.py?at=default
Some issues I have identified are:
* it&
My attempts to reproduce it (I have quite a lot of code that returns JSON
arrays) on the smattering of browsers I had handy resulted in no apparent
vulnerabilities.
On Tuesday, February 17, 2015 at 10:30:20 AM UTC+10:30, Tom Christie wrote:
>
> I haven't dug out sources on this, but I think that
On Wednesday, September 24, 2014 8:24:28 AM UTC+9:30, Shai Berger wrote:
>
> Hi all,
>
> I gave a talk to a local user-group about the migrations in 1.7, and some
> people in the audience raised things they would like to be able to do, and
> are
> not supported by the current framework; thoug
On Wednesday, April 2, 2014 3:35:24 AM UTC+10:30, Andrew Godwin wrote:
>
> Hmm, I'm not sure about this. On the one hand, during the migrations work
> I refactored check constraints for the existing stuff (e.g.
> PostitiveIntegerField) out of the type string and into a separate check
> constra
Some years ago, I discussed adding database-level check constraints into
django: https://groups.google.com/forum/#!topic/django-developers/OJN5kpcseAg
There is also an issue: https://code.djangoproject.com/ticket/11964
I'm thinking about revisiting this, and wanted to get some discussion going
On Friday, February 28, 2014 12:55:31 PM UTC+10:30, waylan wrote:
>
> On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote:
>>
>> normalize_email will indeed allow both us...@example.com and
>> us...@example.com to be different entities. From the user perspective,
>> this is an
I maintain the django-jsonfield module, and I have, as the documentation
suggests, some relatively expensive code in JSONField.db_type.
The documentation is pretty clear on this as being _the_ place to put a
test like this (that checks to see if the database can handle a json field
type, or if
Hi,
I was wondering if there was any reason why fields such as
models.DateField() do not use the SubFieldBase metaclass
trick to ensure they always contain instances of the correct
class?
I'm referring to the description
from
https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#mode
Not sure that I phrased the last bit right: I think my repose framework is
a step in the right direction, but even so I think it probably doesn't do
things the right way.
Matt.
On Wednesday, August 29, 2012 2:57:35 PM UTC+9:30, schinckel wrote:
>
> Hi Tom,
>
> I've knoc
big improvement over how I've done it in the
past.
(I've done some work on a form-based API generation
framework: https://bitbucket.org/schinckel/django-repose. Whilst this is in
use, it's still not really feature complete).
Matt.
--
You received this message because you are subsc
The other thing this breaks is using **kwargs with something loaded from
JSON.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/ynPxXsJZUB8J.
To p
I played around a bit with using this, and got something quite workable
going on.
https://bitbucket.org/schinckel/django-multi-schema
It's really only an exploration, but does show that it can be done.
The problems actually really only got hard once you factor south into the
equation.
I agree: but this means that the actual dispatcher (that, according to the
comments,
"dispatch[es] to the right method", is called handle(), rather than
dispatch.
Perhaps the assignation of request/args/kwargs could happen before dispatch
is
called?
--
You received this message because you a
I am quite interested in this, as most of my coding work has been
developing APIs that get consumed by non-web-browser software.
Lately, I've taken the approach that a Form is the appropriate tool to use
for (de)serialisation: it's already used extensively by the template
rendering (which is in
I'm doing just this in several cases: I packaged up a JSONField into a
re-usable
application: https://bitbucket.org/schinckel/django-jsonfield/overview
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discus
The way I am handling this type of thing (and this is getting into
django-users territory), is to either:
- have a middleware that catches exceptions, and if they are a sub-class of
HttpError, then return them,
- have a framework which handles this, often by having the CBV handle it in
it's di
Yeah, I saw that later when I wrote some tests.
I'm sure I saw the style of failure message with some django app tests I
wrote ages ago: maybe my brain has failed that test and it was a ruby unit
test.
Matt.
--
You received this message because you are subscribed to the Google Groups
"Django
It isn't 'enforced' by Python at a language level, but as dmoisset stated,
it makes the failure messages actually make sense:
"Expected 'foo', got 'bar'".
(paraphrasing failure message: don't have any failing tests to look at right
now. YAY! :)
Matt.
>
--
You received this message becau
Attached is a post that requires all passwords to be:
'correct horse battery staple'
:)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/GBAQF7Io
On Dec 9, 1:57 pm, schinckel wrote:
> On Dec 8, 2:02 pm, nasp wrote:
>
> > You might consider
> > readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.
>
> Thanks: that was the link I needed.
>
> However, I do take exception with the comment:
>
On Dec 8, 9:24 pm, -RAX- wrote:
> By default Admin saves an empty string in those TextFields and
> CharFields defined as null = True.
>
> Whatever the semantic reasons are, this default behavior creates
> problems in those fields which are both unique = True and null = True
> because by saving an
On Dec 8, 2:02 pm, nasp wrote:
> You might consider
> readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.
Thanks: that was the link I needed.
However, I do take exception with the comment:
If a string-based field has null=True, that means it has two
possible values for “no
On Dec 8, 9:28 pm, Andrew Godwin wrote:
> On 07/12/10 23:26, schinckel wrote:
>
>
>
>
>
> > I haven't been able to find any documentation about this, but would be
> > happy to be pointed in the right direction.
>
> > When you use null=True in a field,
I haven't been able to find any documentation about this, but would be
happy to be pointed in the right direction.
When you use null=True in a field, and then use that model in the
admin, it will not save NULL to the database, but will instead save an
empty string (or attempt to).
I think this is
On Apr 7, 12:20 am, Jacob Kaplan-Moss wrote:
> On Tue, Apr 6, 2010 at 9:42 AM, schinckel wrote:
[snip]
>
> A new ticket would be better -- browsers have changed a lot since
> Firefox 1.0.6 (wow, Django's OLD!) -- and the bug's likely to be
> different. You can reference
It seems Safari (Mac, at least) is still plagued by what seems to be
the behaviour described by http://code.djangoproject.com/ticket/348 -
when you have a ManyToMany, and have turned it into a javascript-
enabled filter box pair (SelectFilter2.js), then you get funky
behaviour.
This is fine in Fir
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote:
> I wonder if there is a particular reason why last_login field of is not
> defined as "null=True"? It makes sense to me to have it as null which would
> mean that the user never logged in. Could there be any dependencies relying
> on this field not bein
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote:
> I wonder if there is a particular reason why last_login field of is not
> defined as "null=True"? It makes sense to me to have it as null which would
> mean that the user never logged in. Could there be any dependencies relying
> on this field not bein
On Nov 27, 10:07 pm, noel wrote:
> I really love this application Reinteract. Its an enhancement to
> Python Interactive Shell. And it would be lovely if I can use
> Reinteract with manage.py shell.
Have a look at bpython. I have a command set up where I can run
./manage.py bshell
And I get a
I'm very interested in the idea of expanding the database level
constraints that can be supplied to a database schema, and also
automatically apply the same constraints to the model/view in django.
The various backends that support them, I believe already apply such
constraints for PositiveIntege
On Sep 26, 10:27 pm, Tim Chase wrote:
> > Is there anyone else interested in this?
>
> yes, I'd be interested in seeing some sort of database-level
> CHECK constraint as part of Django. I had been sitting on my
> thoughts until I see the GSoC work done on model-validation wend
> its way toward
40 matches
Mail list logo
