If you're using a PostgreSQL you might want to look at using a tsvector
column instead which will ignore stop words (the, or, of, ...) and map
lexemes to their number of occurrence and position in the lyrics[0].
Assuming you were to index this column you'd be able to efficiently query
it for
Short answer is that you can't; constraints cannot spans across JOINs.
You might be able to use database triggers to emulate though.
Le lundi 28 juin 2021 à 08:08:27 UTC-4, ngal...@gmail.com a écrit :
> I have two models like this
>
> How can I make models constraint based on the dates as shows
Hello Shaheed,
I didn't look at your issue into details but since it involves exclude,
subqueries, an queryset combination and only manifests itself on Django 3.2
I wouldn't be surprised if it was related to some regressions in this area
that are fixed in Django 3.2.1 which is meant to be
Hello Chris,
> It looks like the gis files aren't covered. Is there any way to run tests
and coverage on this code?
The tests for these files won't be run unless you run the suite with a GIS
enabled database backend.
We do it on CI (https://djangoci.com/view/%C2%ADCoverage/) but you can do
This is unfortunately not possible to do through the ORM right now due to
lack of support for filtering against window expressions[0]
Until this ticket is solved you'll have to rely on raw SQL.
Cheers,
Simon
[0] ticket https://code.djangoproject.com/ticket/28333
Le mercredi 4 novembre 2020 à
Unfortunately MySQL doesn't support an equivalent of the RETURNING clause
on PostgreSQL/Oracle.
In other words MySQL only allows to retrieve an inserted row auto id one at
a time through its non-standard LAST_INSERT_ID function.
That prevents any attempts at inserting multiple rows and
I don't think your issue has anything to do with proxy models.
You'll get the exact same error if your use Parent.objects instead of
Child.objects as both will generate the same SQL:
SELECT *
FROM parent
LEFT JOIN foreign ON parent.foreign_id = foreign.id
FOR UPDATE OF parent
In this case
at 10:16 AM Simon Charette > wrote:
>
>> Hello there,
>>
>> By default MySQL interprets providing 0 for an AUTO_INCREMENT PRIMARY KEY
>> as NULL which defaults to increment the field.
>>
>> CREATE TABLE foo (id int auto_increment primary key);
>> INSE
Hello there,
By default MySQL interprets providing 0 for an AUTO_INCREMENT PRIMARY KEY
as NULL which defaults to increment the field.
CREATE TABLE foo (id int auto_increment primary key);
INSERT INTO foo (id) VALUES(0);
INSERT INTO foo (id) VALUES(0);
SELECT * FROM foo;
++
| id |
++
| 1
La documentation de Django est disponible en Français.
Ce message d'erreur est traduit dans cette section:
https://docs.djangoproject.com/fr/3.0/ref/checks/#translation
Tu as deux choix:
1. Ajoute 'fr-fr' à ton setting LANGUAGES tel qu'indiqué
2. Définit ton setting LANGUAGE_CODE = 'fr' plutôt
Django 3.0 only supports Oracle 12.2 and and 18c[0].
Django 2.2 only supports Oracle 12.1+[1]
Django 1.11 supports Oracle 11g but LTS support for it will end in April[2].
In short even if you downgrade to 1.11 LTS you won't get any support from
Django after less than two weeks.
It looks like
If you don't want to operate on Activity instances annotations you can use
the following queryset
Status.objects.annotate(
status_month=TruncMonth('status_date'),
).order_by(
'activity', 'status_month',
).values_list(
'activity', 'status_month',
).annotate(
Hello Ricardo,
I suggest you follow these docs to submit your bug report and link to this
thread.
https://docs.djangoproject.com/en/3.0/internals/contributing/bugs-and-features/#reporting-bugs
I'd mention that the issue is also present if you use
`output_field=DurationField` as
connector types such as AND/OR but the child
> should not
>
>
> On Tuesday, February 18, 2020 at 11:30:40 PM UTC-5, Simon Charette wrote:
>>
>> I suggest you have a look at the "Trees and Graph" section of the
>> Django Packages website[0]. I've personally used MPTT and Treebeard
&
Hello Ricardo,
This could be a regression caused by a patch addressing a regression in
3.0.3[0].
Did you also notice this behaviour on Django 2.2.x or was this project
started from Django 3.0?
>From what I can see though I find it strange that the ExpressionWrapper of
end_total_time
have an
I suggest you have a look at the "Trees and Graph" section of the
Django Packages website[0]. I've personally used MPTT and Treebeard
in the past without too much trouble.
You could also a field able to store composite data structures
such as JSONField or even a dedicated PostgreSQL type[1] to
Hello Thierry,
Django doesn't support support constraints on lookups/expressions but
there's ungoing work to do so[0].
In the mean time you'll have to rely on a `RunSQL` operation in your
migrations to create the constraint.
Cheers,
Simon
[0] https://code.djangoproject.com/ticket/30916
Le
r using a
> `models.F` relation there also doesn't work (see my response to Stephen's
> suggestion).
>
> Thanks,
> Peter
>
> On Monday, 27 January 2020 18:23:28 UTC, Simon Charette wrote:
>>
>> Did you try
>>
>> class Item(Model):
>>
Did you try
class Item(Model):
price = DecimalField()
full_price = DecimalField()
is_on_sale = BooleanField()
class Meta:
constraints = [
CheckConstraint(check=Q(is_on_sale=Q(price__lt=F('full_price'
]
I haven't tried it myself but I would expect
If you are using PostgreSQL I'd suggest using a CIText field[0] with a
unique
constraint[1].
If you are *not* using PostgreSQL your best choice is likely to emulate the
upcoming expression[3] support for UniqueConstraint(Lower('field')) by using
a RunSQL operation that performs the appropriate
Hello Pavel,
This is likely a bug because UniqueConstraint was only recently introduced.
Please file a bug report about it. In the mean time you can add this check
to
your SILENCED_SYSTEM_CHECKS setting to silence it.
Best,
Simon
Le lundi 20 janvier 2020 07:21:26 UTC-5, Pavel Garkin a écrit :
I suspect your usage of `distinct('path')` is causing issues during
prefetching here
as it will prevent different File with the same .path from being prefetched
for two different
folder objects.
You likely want to use `distinct('path', 'folder')` here instead where
'folder' might have a
You are missing an underscore here.
It should be published_date__lte and not published_date_lte.
Cheers,
Simon
Le jeudi 19 décembre 2019 11:40:05 UTC-5, MEGA NATHAN a écrit :
>
> Hi all.
>
> Cannot resolve keyword 'published_date_lte' into field. Choices are: author,
> author_id, comments,
Hello Rich,
Unfortunately the migration framework is not smart enough to resolve this
kind of dependency.
The order of operation/migrations of the makemigrations is generated by the
autodetector which
hardcodes most of its logic.
I would have assumed that constraints were generated _after_
Dear Uri,
> When I use pip to install a package, does it depend on the version of
Python I'm using?
Yes, it does.
> I noticed that Django 3.0 doesn't support Python 3.5. But why does pip
fail?
Pip will respect the supported version metadata of the package. There's no
package available for
nd regards,
> Bill
>
> On Fri, 15 Nov 2019 at 17:19, Simon Charette > wrote:
>
>> Can you reproduce with Django 2.2.7 (releases November 4th, 2019)
>>
>> Le vendredi 15 novembre 2019 06:04:32 UTC-5, Bill Bouzas a écrit :
>>>
>>> Good morning Simon,
>
Hello there,
You'll want to use Coalesce[0] for this purpose.
Model1.objects.order_by(Coalesce('effectual_rating', 'rating').desc())
Cheers,
Simon
[0]
https://docs.djangoproject.com/en/2.2/ref/models/database-functions/#coalesce
Le vendredi 15 novembre 2019 13:32:46 UTC-5, Kev H a écrit :
>
>
> On Thu, 14 Nov 2019 at 16:41, Simon Charette > wrote:
>
>> Hello Bill,
>>
>> Could you give us more details about which version of Django you are
>> using?
>>
>> There was a few Django bugs related to as_sql returning Union[list,
>> tup
So this happened not to be supported in Django 3.0 either.
But https://github.com/django/django/pull/12067 should add support for it.
Le jeudi 14 novembre 2019 15:50:34 UTC-5, Simon Charette a écrit :
>
> For the record I haven' tested the above myself.
>
> It might only work o
For the record I haven' tested the above myself.
It might only work on Django 3.0+ and require you to pass
`output_field=BooleanField()` to Func.
Le jeudi 14 novembre 2019 09:46:48 UTC-5, Simon Charette a écrit :
>
> Hello there,
>
> I guess your example is not the best since this
Hello Bill,
Could you give us more details about which version of Django you are using?
There was a few Django bugs related to as_sql returning Union[list, tuple]
as params that were
fixed in recent release but this one might not have been caught yet.
Cheers,
Simon
Le jeudi 14 novembre 2019
Hello there,
I guess your example is not the best since this check could be defined on
Author.Meta.constraints
directly but if you wanted to define such a check on Book anyway you'll
have to define a function
and refer to it in the check constraint using Func.
Using RunSQL in your migrations
Hello Patrick,
>From what I understand you are relying on unmanaged (Meta.managed=False)
models
to use the ORM to query an externally managed database.
The part you missed here is that the ORM maps ForeignKey fields to database
columns with
a "_id" suffix by default. In your case that means it
This was tracked in https://code.djangoproject.com/ticket/30673 and fixed
and 2.2.5[0]
Cheers,
Simon
[0]
https://github.com/django/django/commit/1265a26b2fa3cbd73a2bccd91b700268bc28bc07
Le jeudi 17 octobre 2019 10:31:50 UTC-4, Sijoy Chirayath a écrit :
>
> I am changing one of my application
Hello there,
>From looking at your code (super() calls) it seems like your are using
Python 2.
We've seen similar reports about stdlib functions hiding system level
exceptions
instead of surfacing them[0] so that might it.
It's hard to tell without the full traceback though.
Best,
Simon
This error comes from ForeignObject.resolve_related_fields[0].
If you are using ForeignObject directly you have an incompatible
from_fields and to_fields
definition. It's hard to debug further without the full traceback.
Cheer,
Simon
[0]
It's hard to tell what's wrong from the limited context you provided but
whatever code
is in django_sites_extensions is highly suspicious.
Best,
Simon
Le jeudi 5 septembre 2019 18:02:49 UTC-4, gh a écrit :
>
> Traceback (most recent call last):
>File
>
Django 2.0 only supports MySQL 5.5+.
I suspect you're getting a syntax error when Django tries to create a table
mapping
a model with a DateTimeField since it resolves to DATETIME(6) which is not
supported
on MySQL < 5.5.
Cheers,
Simon
Le mardi 3 septembre 2019 09:58:19 UTC-4, johnsi rani a
I'm afraid the ORM doesn't support aggregation over unions yet else I would
have expected the following to work.
objects = Model.objects
querysets = (
objects.filter(city=city).values(
'date', weighted_car_crashes=F('car_crashes') * weight
) for city, weight in weights
)
union =
Hello there,
These queries should be cached by ContentTypeManager[0] so something must
be broken
in your Django install or monkey patching this method.
Simon
[0]
https://github.com/django/django/blob/7da6a28a447dc0db2a2c6ef31894094eb968f408/django/contrib/contenttypes/models.py#L34-L44
Le
Hello,
assuming you have a FullMatch model mapped to your FullMatches table
the following should do.
FullMatch.objects.filter(
job_id=job_id,
).values(
seq=Concat('loading_code', ...),
ids=Concat('loading_id', ),
).annotate(
total=Count('*'),
).order_by('-total')
Using
Hello Don,
Django logs all database queries to the django.db.backends logger. It is not
redirected to STDOUT when using the default settings.LOGGING configuration
but you can enable it yourself[0].
If you wan to assert against a fixed number of queries you can use the
assertNumQueries context
Hello Don,
If you're on Django 2.2+ you should use bulk_update for this purpose[0]
TestThing.objects.bulk_update((
TestThing(id=id, value=new_value)
for id, value in new_values.items()
), ['value'])
Under the hood it performs a SQL query of the form
UPDATE ... SET value = (CASE WHEN
Assuming you have a model definition `Salesperson` you could use
Salesperson.object.annotate(
sales_amount=Sum('sales__sales_amount'),
)
But given you mentioned 'salesperson' is a text field you can do
persons = Sales.objects.values('salesperson').annotate(
Hello Victor,
You should avoid performing database queries at module loading level as the
code will
necessary crash if the database is missing or unmigrated.
I suggest you lazily define widgets instead by using a cached property[0]
class PlaceWidget(widgets.MultiWidget):
def __init__(self,
It's hard to tell without the full traceback but Django 1.11 doesn't
support Python 3.7 so it'd
start by either using Django 2.2 or downgrading to Python 3.6
Cheers,
Simon
Le mercredi 19 juin 2019 08:16:51 UTC-4, Ezequias Rocha a écrit :
>
> Hi everyone
>
> I am doing a modeling of my database
Hello Dan,
I'm not aware of any third party library handling this but a simple way to
achieve
what you're after would be to subclass ModelForm in order to override save()
and pass commit=False in your super() call.
e.g. (untested)
class UpdateFieldsModelForm(ModelForm):
update_fields =
8.0/lib/libsqlite3.dylib
>
>
> On Sat, Jun 15, 2019 at 8:16 AM Simon Charette > wrote:
>
>> I meant Django 2.0 -> 2.1. As long as you are using Django 2.2 with
>> SQLite 3.20+
>> the slowdown I mentioned should be effective.
>>
>> Simon
>>
>
ses, it's
> getting slower as the version of Django increases.
>
> On Sat, Jun 15, 2019 at 7:20 AM Simon Charette > wrote:
>
>> Hi Mark,
>>
>> It's hard to tell exactly what's going on without more details but
>> assuming you are running tests
>> against
Hi Mark,
It's hard to tell exactly what's going on without more details but assuming
you are running tests
against SQLite the 2.1 to 2.2 slowdown is likely caused by the fact
database constraints are
now checked of each TestCase[0].
Cheers,
Simon
[0]
Hey David,
Could you try explicitly defining an objects manager on your User model and
see it if helps.
e.g.
from django.contrib.auth.models import UserManager
class User(AbstractUser):
... # fields
objects = UserManager()
I'm also having trouble reproducing locally though.
Simon
I assume you are either using a Subquery annotation that returns
multiple results or an __in lookup against a query with multiple columns.
I vaguely remember something changed in this area but it was documented
in one of the 2.0, 2.1 or 2.2 release notes.
Best,
Simon
Le mardi 23 avril 2019
Hello Thorsten, this is a change document in the 2.2 release notes[0].
There's even a resolution example for a django.jQuery dependency like you
have
> For example, widgets depending on django.jQuery must specify
> js=['admin/js/jquery.init.js', ...] when declaring form media assets. [1]
No form validation is implemented for UniqueConstraint(condition) yet as
that would require
a non-trivial refactor of how it's performed. It was discussed during the
feature development[0].
I'd suggest you override you form or your model's clean() method to perform
the validation
yourself
This is effectively failing because of a mechanism added in 1.10 to protect
against BREACH attacks[0] by salting the CSRF token.
I'm not aware of any way to disable this mechanism but testing against the
exact HTML returned from a view seems fragile.
I suggest you use assertContains[1] (with or
I'm not sure where r_id comes from but Model.save usually deals with any
expression correctly
so you could try using a subquery assignment and see if it works.
e.g.
entry = Entry.objects.create(
start=Subquery(
Recurrence.objects.filter(pk=r_id).values('start_time')[:1]
)
)
y work? delete all app permission and use,
> create_permissions to recreate them
> b) How do I know to which db table a given permission points? Or does it
> point to a model?
>
> On Mon, Mar 18, 2019 at 6:38 AM Simon Charette > wrote:
>
>> Hello Yevgeny,
>>
On Sun, Mar 17, 2019, 9:21 PM Simon Charette > wrote:
>
>> Hello Yevgeny,
>>
>> I don't have magic solution to suggest to you given the current state of
>> your
>> permission data after a few iterations but I just wanted to let you know
>> that
>&
Hello Yevgeny,
I don't have magic solution to suggest to you given the current state of
your
permission data after a few iterations but I just wanted to let you know
that
it's a known issue[0] and a contributor is actively working on getting it
fixed[1].
Cheers,
Simon
[0]
Hello HM,
I know that some changes have been made to avoid unnecessary foreign key
rebuilds on some option changes.
Are you experiencing this on 2.1 and 2.2 pre release?
Simon
Le vendredi 1 mars 2019 02:40:01 UTC-5, HM a écrit :
>
> I added "related_name" to an exiting ForeignKey and checked
Hello Felix,
month = ...
year = ...
Expenses.objects.filter(
year=year,
).values(
area_name=F('area__name'),
element_name=F('element__name')
).annotate(
year_sum=Sum('cost'),
month_sum=Sum('cost', filter=Q(month=month)),
)
Should generate SQL along the following lines on
Hello Philoj,
> Does this mean that the above code example will raise
TransactionManagementError...
It won't cause a TransactionManagementError because of the lazy nature of
queryset.
Even if the QuerySet.select_for_update() call is made outside of the atomic
block the query
is really only
I meant, and *not* "Building a queryset" in my previous reply.
Le vendredi 15 février 2019 14:18:27 UTC-5, Simon Charette a écrit :
>
> Hello Philoj,
>
> > Does this mean that the above code example will raise
> TransactionManagementError...
>
> It won't
Your DirectorForm model form doesn't include 'Leave_current_balance' in
it's Meta.fields
hence no form field is generated for it.
Cheers,
Simon
Le jeudi 14 février 2019 17:50:21 UTC-5, suabiut a écrit :
>
> Hi,
>
> I have two models many to many relationships, I am trying to update the
> field
Hello there,
I haven't tried it myself but you could try subclassing
django.utils.log.AdminEmailHandler
to rely on the better-exceptions[0] package to _better_ format exceptions
sent in text
emails or simply set the include_html option[1] to True in your LOGGING
configuration to
get report
Hello Nick,
It isn't possible to reference columns in a LIMIT clause AFAIK.
I'd suggest you use a RowNumber[0] window function ordered by your number
column in a
subquery and filter on the annotated value in the outer query.
Cheers,
Simon
[0]
() in django.contrib.auth.handlers.modwsgi.
Best,
Simon
Le lundi 28 janvier 2019 10:16:30 UTC-5, Simon Charette a écrit :
>
> Hello there,
>
> That looks like a Django bug to me as auth.get_user_model() should only be
> performed
> from within the check_password() function as it wi
Hello there,
That looks like a Django bug to me as auth.get_user_model() should only be
performed
from within the check_password() function as it will certainly crash at the
module level.
You should file a bug report so it gets addressed[0].
Best,
Simon
[0]
You can use the category kwarg of filterwarnings[0] to pass the Django
deprecation
warning classes.
They can be found in the django.utils.deprecation module. (e.g.
RemovedInDjango30Warning).
Cheers,
Simon
[0]
You can use a Func expression for this purpose[0]
Employee.objects.annotate(
emp_number_suffix=Func('emp_number', Value('-'), -1,
function='substring_index'),
).filter(
emp_number_suffix='111',
).values('emp_number')
Cheers,
Simon
[0]
ile
> "/home/gamesbook/.virtualenvs/s2s/local/lib/python2.7/site-packages/django/db/utils.py",
>
> line 198, in __getitem__
> backend = load_backend(db['ENGINE'])
> File
> "/home/gamesbook/.virtualenvs/s2s/local/lib/python2.7/site-packages/django/db/utils.
Hello Derek,
There's no setting but this is controlled by the allows_auto_pk_0 feature
flag [0].
Database feature are set to the default database configurations so Django
can
minimized the number of introspection queries required to work appropriately
each time a connection is opened.
In order
It looks like you configured your CMS_CACHE_DURATIONS setting as an
integer instead of a dict with a 'content' key pointing to an integer[0].
In other words you did
CMS_CACHE_DURATIONS = 42
Instead of
CMS_CACHE_DURATIONS = {'content': 42}
Cheers,
Simon
[0]
Given choices are defined at the module level I guess you could
iterate over objects defined in each `sys.modules` (or the ones
likely to define choices) and use the `is` operator to compare all
of them to the field choices.
This will perform badly and shouldn't be used for anything else
than one
t be sorted out by a different mechanism?
>
> Thanks,
>
> Dakota
>
> On Friday, December 7, 2018 at 7:42:09 AM UTC-5, Simon Charette wrote:
>>
>> Hello Dakota,
>>
>> Migration.dependencies should really have been defined as a set from the
>> start
>> a
Hello John,
Did you try switching to the Jinja2 form renderer[0] to see if it helps?
I've not
tried it myself but I heard it makes a significant difference.
Cheers,
Simon
[0] https://docs.djangoproject.com/en/2.1/ref/forms/renderers/#jinja2
Le vendredi 7 décembre 2018 08:30:48 UTC-5, John a
Hello Dakota,
Migration.dependencies should really have been defined as a set from the
start
as Django doesn't care about their order anyway.
I unfortunately cannot provide a work around but I suggest you submit an
improvement/cleanup ticket to make the order deterministic. It should be
a
Hello Daniel,
It's hard to tell was causes the exception without digging a bit more but
based on your mention of multiple sums I assume you are trying to work
around the cross join of multiple table annotations?
I understand you simplified your query but from what I can see right now
it can be
Hello David,
The current latest version of the Django 1.11 serie doesn't support Python
3.7[0] but
1.11.17, which is still unreleased[1], should per popular demand[2].
Until 1.11.17 is released I'd advise you either stick to Python 3.6 or
upgrade to Django 2.0+.
Cheers,
Simon
[0]
Hello there,
Django 2.1 dropped support for MySQL 5.5[0] as the end of
upstream support is December 2018.
You'll have to update to a more recent version to use Django 2.1+.
Cheers,
Simon
[0]
https://docs.djangoproject.com/en/2.1/releases/2.1/#dropped-support-for-mysql-5-5
Le dimanche 2
Hey there,
I just wanted to clarify that the behavior of including the Meta.ordering
fields in aggregation grouping been around for a while and Django 2.2
deprecates it to deal with the exact type of confusion you experienced here.
Best,
Simon
Le dimanche 2 décembre 2018 08:51:17 UTC-5, Coder
>From that point you should post to the developer mailing list as it's
reaching more people than the ticket tracker[0].
That should give the opportunity to more people to chime in and provide
feedback.
Thanks for tackling this issue by the way, this sure is a source a
confusion for a lot of
Dan,
The root of the issue here is that you query is asking to retrieve all
fields from
the Parent table and perform an aggregation on the JOIN'ed child table.
That results in the following query
SELECT parent.*, MAX(child.updated_timestamp)
FROM parent
JOIN child ON (child.parent_id =
Hello Matthew,
I'm going to assume no foreign keys are pointing to the model "Foo" you are
trying to move from the app "old" to "new". If it's the case then simply
repoint
them and run makemigrations once the following steps are completed. You
could wrap the generated AlterField in
Hello there,
I think you just hit #29890[0], a bug present in Django in 2.0+ and fixed
in Django 2.1.3
which should be released today[1].
Simply updating to 2.1.3 when it's released should address your issue.
Cheers,
Simon
[0] https://code.djangoproject.com/ticket/29890
[1]
The reason why assertIs is used instead of assertFalse is that the latter
actually tests for falsy values and can sometimes hide bugs.
For example, assertFalse(0) and assertFalse(None) will pass and
assertTrue(42) will as well.
If you're testing a method that is supposed to return a boolean
://github.com/django/django/blob/66ac7a129a70a225adc263602bcf7f5750698e8d/django/contrib/auth/models.py#L428-L433
Which is why I suspect you have Django 2.0+ installed.
Cheers,
Simon
Le jeudi 11 octobre 2018 14:58:33 UTC-4, Simon Charette a écrit :
>
> Are you sure you are using Django 1.11?
>
&g
Are you sure you are using Django 1.11?
What does ./run.sh manage --version yields?
User/AnonymousUser was made a property in Django 2.0+ which I assume your
version of Django CMS is not compatible with.
Best,
Simon
Le jeudi 11 octobre 2018 14:26:27 UTC-4, Stefan Bethke a écrit :
>
> First
Hey Mike,
Please provide the full traceback.
Also, since all your conditions are ANDed you could use a dict to build
filter() kwargs instead of Q() objects.
Cheers,
Simon
Le mercredi 19 septembre 2018 10:36:13 UTC-4, Matthew Pava a écrit :
>
> I’m not entirely sure if the error is from your Q
Hello Michèl,
I'm pretty sure you hit #28862[0] which should be fixed in Django 2.2.
Here's the PR resolving it if you're curious about it[1].
Cheers,
[0] https://code.djangoproject.com/ticket/28862
[1] https://github.com/django/django/pull/10178
Le mercredi 12 septembre 2018 06:29:30 UTC-4,
event_time|date:"g:i A" }}
> {{i.event_type|title}} -
> {{i.title|title}}
> Purchase Reservation ${{i.price}} Seats
> Remaining ### VARIABLE HERE ###
>{{ i.description|safe}}
>
>
>
>
>
>
>
>
>
>
>
>
Hello there,
You should be able to achieve what you're after by using annotations[0].
In your case you'll want to declare your Event and Reservation relationship
explicitly by using
a ForeignKey
class Event(models.Model):
...
seating = models.PositiveIntegerField(default=0)
class
There's two open tickets to work around this issue.
https://code.djangoproject.com/ticket/25464 which allows passing queryset
override to be used for retrieval and another one that I can't currently
find that allows specifying that a subquery should be used instead of a an
IN clause.
Simon
Hey James,
Just to add to what was already said there's a ticket tracking the addition
of
database level foreign constraints.[0]
Cheers,
Simon
[0] https://code.djangoproject.com/ticket/21961
Le samedi 23 juin 2018 09:56:23 UTC-4, Tomasz Knapik a écrit :
>
> If you search about it on the
Hello Gallusz,
This is probably caused by the `Financial.Meta.ordering` that you didn't
include in your snippet.
I assume it's currently defined as ('name', 'financial_year')?
In order to get rid of it you'll want to clear it up using an empty call to
order_by():
Hello André,
> Is there a way to force Django to close the DB connection after each
operation (unless we're in an atomic block)?
The only way I can think of achieving that is by bundling your own database
backend subclass
and override execute() and the cursor subclass to close the connection
Hello Olivier,
Since JSON objects can only have string keys[0] I'd suggest you always use
strings
as dict keys on the Python side to avoid having to deal with both cases.
Another solution would to subclass JSONField to override the from_db_value
method
to turn keys into integer when retrieved
Hello there,
If you are using PostgreSQL you can achieve it using ArrayAgg[0]
queryset =
MetaData.objects.annotate(values=ArrayAgg('metadatavalue__value'))
map = dict(queryset.values_list('name', 'values'))
Cheers,
Simon
[0]
Hello Yue,
You probably have a model with a ForeignKey where you set on_delete=True.
Best,
Simon
Le mercredi 28 mars 2018 07:11:04 UTC-4, yue lan a écrit :
>
> Hi,
> I think I found a bug of django. My python version is 3.6.3 and Django is
> 2.0.3. And the bug is showed below:
>
> File
Hello Anon,
Django doesn't use database level ON DELETE constraints and emulates them
in Python
to dispatch pre_delete/post_delete signals. As long as you're using the ORM
to perform
the deletion you shouldn't encounter constraint violations.
There's a ticket to add support for database level
1 - 100 of 292 matches
Mail list logo
