Thanks, Florian. That clarifies things. I didn't realize collectstatic was
using two backends, but it makes sense. And thanks for putting up with me
not being up to speed on the IRC discussion.
On Tuesday, October 9, 2012 1:20:39 AM UTC-7, Florian Apolloner wrote:
>
> Hi Stephen,
>
> On Tuesday,
Hi Stephen,
On Tuesday, October 9, 2012 7:28:43 AM UTC+2, Stephen Burrows wrote:
>
> I'm a little confused by the track the discussion took recently... my
> impression was that the solution would *not* be to change from
> last_modified to a checksum, or to add an additional checksum method.
> I
Hi Jeremy,
On Tuesday, October 9, 2012 5:15:04 AM UTC+2, jdunck wrote:
>
> Would it be reasonable to have a backend-specific hook to determine a
> fingerprint, where that could be mtime or md5 or whathaveyou as long as
> equality (or maybe ordering) works?
>
Given our discussion in IRC yesterda
I'm a little confused by the track the discussion took recently... my
impression was that the solution would *not* be to change from
last_modified to a checksum, or to add an additional checksum method.
Instead, storage backeds could support a has_changed method, which could be
overridden to pr
Would it be reasonable to have a backend-specific hook to determine a
fingerprint, where that could be mtime or md5 or whathaveyou as long as
equality (or maybe ordering) works?
On Oct 8, 2012, at 10:23 AM, Alex Ogier wrote:
> On Mon, Oct 8, 2012 at 1:06 PM, ptone wrote:
> While git may be
On Mon, Oct 8, 2012 at 1:06 PM, ptone wrote:
> While git may be common, and your problem not unique - this is still a
> condition of your dev environment rendering modification dates invalid.
> There might be other situations where this is the case (I've run into
> scripts that muck with modifica
On Monday, October 8, 2012 8:49:58 AM UTC-7, Dan Loewenherz wrote:
>
>
> > On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel
> > >
>> wrote:
>> Then, frankly, this is a problem of the storage backends, not Django's.
>> The S3BotoStorage backend *does* have a modified_time method:
>>
>>
>> http
On Mon, Oct 8, 2012 at 3:50 AM, Jannis Leidel wrote:
> You're able to ask S3 for the date of last modification, I don't see why a
> comparison by hashing the file content is needed additionally. It'd have to
> download the full file to do that on Django's side and I'm not aware of a
> API for get
> > On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel wrote:
> Then, frankly, this is a problem of the storage backends, not Django's.
> The S3BotoStorage backend *does* have a modified_time method:
>
>
> https://bitbucket.org/david/django-storages/src/1574890d87be/storages/backends/s3boto.py#cl-298
On 08.10.2012, at 07:38, ptone wrote:
> so after scanning this thread and the ticket again - it is still unclear that
> there could be a completely universal solution.
>
> While it would be nice if the storage API had a checksum(name) or md5(name)
> method - not all custom storage backends ar
On 06.10.2012, at 19:48, Dan Loewenherz wrote:
> Hey Jannis,
>
> On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel wrote:
>
> On 30.09.2012, at 23:41, Dan Loewenherz wrote:
>
> > Many backends don't support last modified times, and even if they all did,
> > it's incorrect to assume that last
so after scanning this thread and the ticket again - it is still unclear
that there could be a completely universal solution.
While it would be nice if the storage API had a checksum(name) or md5(name)
method - not all custom storage backends are going to support a single
checksum standard. S3
This issue just got me again tonight, so I'll try to push once more on this
issue. It seems right now most people don't care that this is broken, which
is a bummer, but in which case I'll just continue using my working solution.
Dan
On Sat, Oct 6, 2012 at 10:48 AM, Dan Loewenherz wrote:
> Hey J
Hey Jannis,
On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel wrote:
>
> On 30.09.2012, at 23:41, Dan Loewenherz wrote:
>
> > Many backends don't support last modified times, and even if they all
> did, it's incorrect to assume that last modified time is an accurate
> heuristic for whether a file
On 30.09.2012, at 23:41, Dan Loewenherz wrote:
> Many backends don't support last modified times, and even if they all did,
> it's incorrect to assume that last modified time is an accurate heuristic for
> whether a file has already been uploaded or not.
Well but it's an accurate way to decid
On 28.09.2012, at 05:38, Dan Loewenherz wrote:
> On Thu, Sep 27, 2012 at 4:13 PM, Carl Meyer wrote:
> Hi Dan,
>
> On 09/27/2012 04:47 PM, Dan Loewenherz wrote:
> > Just updated the ticket.
> >
> > As I commented, the heuristic for checking if a file has been modified
> > lies in line 282 of co
I think it's an API limitation. Many backends don't support last modified
times, and even if they all did, it's incorrect to assume that last
modified time is an accurate heuristic for whether a file has already been
uploaded or not. It might be a better idea to let the backends decide when
a file
I use S3 as well, and I have seen cases where files get copied that I know
don't need to be. That being said, it was never so slow that it was an
issue for me. Is there clear evidence that this is something which can't be
handled by the S3 backend due to an inadequate API on the django side?
--
+1
I like this implementation.
--
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/-/eKXUlc0TKgYJ.
To post to this group, send email to django-develope
On Thu, Sep 27, 2012 at 4:13 PM, Carl Meyer wrote:
> Hi Dan,
>
> On 09/27/2012 04:47 PM, Dan Loewenherz wrote:
> > Just updated the ticket.
> >
> > As I commented, the heuristic for checking if a file has been modified
> > lies in line 282 of collectstatic.py:
> >
> > *if not prefixed_path in sel
Hi Dan,
On 09/27/2012 04:47 PM, Dan Loewenherz wrote:
> Just updated the ticket.
>
> As I commented, the heuristic for checking if a file has been modified
> lies in line 282 of collectstatic.py:
>
> *if not prefixed_path in self.copied_files:*
> *
> return self.log("Skipping '%s' (already copie
Just updated the ticket.
As I commented, the heuristic for checking if a file has been modified lies
in line 282 of collectstatic.py:
*if not prefixed_path in self.copied_files:*
*
return self.log("Skipping '%s' (already copied earlier)" % path)
*
https://github.com/django/django/blob/master/dja
On Thu, Sep 27, 2012 at 12:51 PM, Dan Loewenherz wrote:
> The problem I've run into is that collectstatic copies all files,
> regardless of whether they already exist on the destination.
No, as noted in the ticket, which has been closed needsinfo, staticfiles
already only copies modified files.
Good idea, but shouldn't it be a per-storage thing? Perhaps this could be
done with a couple of callbacks in the collectstatic run:
- Before collectstatic starts, so the storage backend can pick up its
inventory from the remote
- One called for each file that would be copied, and that c
On Thu, Sep 27, 2012 at 6:51 PM, Dan Loewenherz wrote:
> Hey all!
>
> This is a feature request / proposal (one which I'm willing to build out,
> given that I've already developed a solution for my own uploader).
>
> [...]
>
> I'll contribute the patch. I know there is not a lot of time before the
I like this feature and have recently been thinking of implementing
such on my own myself.
+1 for the feature request.
On 9/27/12, Dan Loewenherz wrote:
> Hey all!
>
> This is a feature request / proposal (one which I'm willing to build out,
> given that I've already developed a solution for my o
Hey all!
This is a feature request / proposal (one which I'm willing to build out,
given that I've already developed a solution for my own uploader).
I run a consulting business that helps small startups build initial MVPs.
When the time ultimately comes to deciding how to store static assets, my
27 matches
Mail list logo
