Aymeric,
That's an interesting idea I hadn't considered -- perhaps storages could
also then be marked trusted and untrusted, and processing/display of those
files could take it into consideration. I agree the security requirements
are different.
Florian,
I agree that changing APIs would cause
Hi Jeremy,
That could be useful for any website that gets some of its assets from the code
(JS, CSS), others from a CDN (eg. product photos), others from another CDN (eg.
tutorial illustrations), etc. However we'd have to make sure it beats the
common solution of having a model instance for eac
Hi Jeremy,
To be honest I don't really see the gains (yet). How are those FILE_STORES
supposed to handle the *_URL bits of those settings? Instances in settings
are imo not going to fly, we should stay with strings to classes/instances
there for now. So how would the 'static' or 'dynamic' insta
Right now, I think that static/media handling is fairly confused in the
documentation, and a bit confused in the code itself.
We have a few special-cases floating around:
default_storage (needed for legacy before storage backends)
staticfiles_storage (needed for collectstatic/handling)
{
On Sep 29, 2014, at 2:46 PM, shmengie <1st...@gmail.com> wrote:
> Merge -- bulk loading foreign data -no guaranty
>
> upsert -- insert or update row w/confidence.
Sounds like a difference without a distinction.
Let spin it a different way: the MERGE syntax, and broad semantic, is fine as
it i
Hi Ramiro,
On 09/27/2014 06:13 AM, Ramiro Morales wrote:
> The names of directories with translations on disk are actually GNU
> gettext locale names[1] as opposed to language names[1] (the ones in
> the Accept-Language HTTP header and discussed above.)
>
> It does specify that the part after the
On 09/29/2014 01:56 AM, Anssi Kääriäinen wrote:
> I think we could use UPSERT for our .save() logic. Django's save()
> method is defined as:
> - Insert a row in to the database if there isn't already a matching
> row for the saved model's primary key
> - Otherwise update the row
>
> This is cu
To upsert or to merge. Sparked a lot more emotion than I would have
anticipated.
Both ideas, have similiar functionality, they solve marginally different
problems.
Both have the objective of reducing client server traffic involved with pk.
Merge -- bulk loading foreign data -no guaranty
ups
I think we could use UPSERT for our .save() logic. Django's save()
method is defined as:
- Insert a row in to the database if there isn't already a matching
row for the saved model's primary key
- Otherwise update the row
This is currently implemented as "try to update, if nothing was updated,
