81–90 of 103 posts
interestingly enough, here's the original commit that defaulted `validate=True`: https://github.com/boto/boto/commit/95939debc3813468264159d5... EDIT : Looks like the original committer is an Amazon employee.
https://github.com/boto/boto/commit/95939debc3813468264159d5...
Earlier quoted context omitted.
That's why you should avoid using default arguments in library functions.
Great point! I have never heard that, but it makes perfect sense. Hopefully I will remember in the future.
Earlier quoted context omitted.
I kind of agree with garnaat's reply, if they just suddenly change the default from TRUE to FALSE they're going to break backwards compatibility with anyone using the library and worse still in a really subtle way! All they can really do at this stage is add a warning to the documentation and hope that new people using the library figure out the significance.
That's why you should avoid using default arguments in library functions.
That's a crap default and a crap name. It should be prefetch_all_keys=False. (edit: and some documented reason WHY you would want to do such a thing) I ran into this recently when making my own s3 sync tool, because the commonly used tool is completely broken (requires something called a 'config file' to function). But I didn't pay it too much mind, because I forgot the price discrepancy for ListBucket calls. PS if y…
> It should be prefetch_all_keys=False. It does not prefetch any key (maxkeys is set to 0), it performs a query on the bucket to validate that the bucket exists and blow up if the bucket does not exist. With validate=False, you can call get_bucket and get a bucket object where no remote bucket exists.
Two manual work-arounds that come to mind:
- store a list of created buckets as keys in another bucket.
- store a dummy file in each bucket you create.
Either method allows you to check the existence of the bucket with a GET request rather than a more expensive LIST request, but both are hackish. It seems like this is functionality S3 should already provide cheaply.
Earlier quoted context omitted.
Why are you comparing S3 costs to "just" HDDs? HDD's aren't web enabled and require other hardware to run and keep running.
A more accurate comparison would be a BackBlaze Storage Pod [0] [0] http://blog.backblaze.com/2013/02/20/180tb-of-good-vibration...
How to save 95%: don't use AWS long-term, buy dedicated hardware. http://blog.backblaze.com/2013/02/20/180tb-of-good-vibration...
Earlier quoted context omitted.
A more accurate comparison would be a BackBlaze Storage Pod [0] [0] http://blog.backblaze.com/2013/02/20/180tb-of-good-vibration...
That's not enough. Don't forget that Amazon automatically duplicates your data in multiple physical locations.