> You can avoid those couple of joins by making your referenced table primary
> key what
> your enum value would have been and simple not joining it.
> In this case you would simply use your referenced table for data integrity
> through
> foreign constraint enforcement.
True, but when defining
Hi Gavin,
I've lost track of how many times I've written that exact code when setting
up a new box - I just didn't wrap it up as a management command. There's a
similar testing cycle with new cache settings.
My only concern would be the one that Tim expressed - that it's ultimately
a one line she
>
> Contributing to contrib.postgres is a possible
> option, but it's not really a postgres specific feature -- almost all
> of the major database vendors support it (sqlite being as always the
> obvious exception).
>
This option worries me. I definitely do not like the idea of building a
fe
> On that note, I'm kind of worried about your assertion that types in contrib
libraries aren't required to support automatic migration. Since migrations
were added, we've added support for migrations in most of our custom field
types.
To clarify, custom fields provided in contrib.postgres are aut
> I try to keep myself out of philosophical arguments. Reference tables
> have a purpose (when you're dealing with a set of values that aren't
> fully known when you're defining the dataset (eg. custom application
> error code tables)), but when the dataset _is_ known in advance an
> enum wil
> The admin isn't "broke" in that is still does what it was designed to do
in 2005 or whatever.
The django admin was designed to do is basic CRUD operations. It does a
good job of that.
> We simply stopped including the admin in every project we build—and I
mean deleting every admin.py and taking
I opened a ticket for this but was asked to discuss it on the mailing list.
When configuring django to send emails through an SMTP server, there are
usually many different settings to try to get it to work. I've written a
management command that just sends an email to make testing the settings
On Thursday, February 26, 2015 at 10:25:02 AM UTC-6, Thomas Leo wrote:
>
> I've opened a ticket [1] to implement the popups in the admin as modal
>> instead
>> of windows. I'm no UI/UX expert but modals are more or less the standard
>> today,
>> windows looks like a relic from the 2000s.
>
>
>
> I've opened a ticket [1] to implement the popups in the admin as modal
> instead
> of windows. I'm no UI/UX expert but modals are more or less the standard
> today,
> windows looks like a relic from the 2000s.
If it ain't broke don't fix it. The django admin is awesome, the reason it
ha
Some general responses to your points:
Database support
Yep, not all databases support enums and not all support them the same
way. That's par for the course when you're trying to abstract across
multiple implementations of the same pseudo-standard.
Vendor lock-in
Enums are hardly vendor lock-in,
I kinda like the idea of enum fields, but I feel they are likely better in
theory than in practice. In theory I said I would introduce one as part of
contrib.postgres, but I've been putting it off as I'm unconvinced whether
it is necessarily ideal anyway when compared to choices or reference tables
11 matches
Mail list logo
