Adam, here's a ticket about allowing custom Meta attributes:
https://code.djangoproject.com/ticket/5793. I guess it would be better to
have a separate thread for that discussion.
On Tuesday, February 14, 2017 at 6:22:08 PM UTC-5, Adam Johnson wrote:
>
> Sorry for the terrible pun here, but I'd l
Sorry for the terrible pun here, but I'd like to suggest the
meta-feature... allowing 3rd party apps to add their own options to Meta
classes. If there was a sensible API for this (or if Django just copied all
attributes defined in Meta onto _meta blindly), Django wouldn't have to add
the translata
Thanks for responding Shai.
I will take this question to django-users.
I am familiar with the filter().update() with the F('volume_count')
that works like a charm for updating one table row by checking the counter
against a limit and incrementing.
I was wondering if this elegent query-filter/
Hi Sarvi,
This list is intended for discussions about developing Django itself; your
question is about writing code using Django, and belongs to the django-users.
That said, please look up database transactions and database locks, and the
relevant Django APIs -- transaction.atomic() and queryse
I have 2 tables Cluster and Node, each having a volume_limit and
volume_count column in it.
To atomically check and increment the volume count for a Cluster and Node I
do the following
updated = Cluster.objects.filter(id=cluster_id,
volume_count__lt==F('volume_limit')).update(volume_count =
F(
W dniu wtorek, 14 lutego 2017 16:19:48 UTC+1 użytkownik jp...@yourlabs.org
napisał:
>
> However, there's a third alternative to changing Meta that may be worth
> suggesting: adding a new Field attribute ie. translatable=True, which could
> be default for CharField and TextField perhaps. It might
Le 14. 02. 17 à 16:31, Patryk Zawadzki a écrit :
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least
clean solutions as they mean none of the translated fields can be marked
as required. For other solutions (
Le 14. 02. 17 à 16:16, j...@yourlabs.org a écrit :
(...)
However, there's a third alternative to changing Meta that may be worth
suggesting: adding a new Field attribute ie. translatable=True, which
could be default for CharField and TextField perhaps. It might even turn
to be an advantage that n
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least clean
solutions as they mean none of the translated fields can be marked as
required. For other solutions (depending on separate tables and
registration)
Django itself includes excellent i18n features for everything, except for
model data: but this can be improved, even in a multi-milestone fashion
starting with Claude's feature idea which is why I support it and I will
restrain myself from talking about internal implementation details which
con
Hi Raphael,
Le 14. 02. 17 à 14:53, Raphael Michel a écrit :
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not ye
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not yet ready to bless one of them, I have a
feeling that we never wi
Dear developers,
I'd like to suggest an addition to the Django Model definitions to ease the
implementation of translatable model fields. There are currently several
third-party applications for model translation, and even if I think we are
not ready yet to bless one of them to be included in c
I posted on the ticket before reading this thread. Whoops. As mentioned
above it's impossible to always convert user input into the output provided
by the database without doing a round trip, because there are driver data
adapters, and django converters that both get a chance at modifying the
d
Agreed - ensuring that this works in the general case is not reliable.
On 13 February 2017 at 15:51, Adam Johnson wrote:
> What do you think? Absent a better suggestion, we could document this
>> pitfall so that there's something to point to when related tickets come in.
>
>
> +1, as Aymeric poi
15 matches
Mail list logo
