Learn More
Resend Email
4
AlmondSauce
5y

Eurgh, sometimes there's just *no need* to change stuff between major API versions - such as the AWS secret key being read from aws.secretKey in v1 of the AWS Java SDK, and aws.secretAccessKey in v2.

Just spent way too long to admit wondering why the secret key wasn't being picked up before realising the above. Doesn't help we have multiple projects on differing major versions of the SDK either.

rant
Favorite
Ranter
Comments
  • 1
    5y
    Yeah, def. I incorporated this in a compensating abstraction for an AWS sqlpad resolver my husband and I wrote. As long as breaking changes are documented it doesn't other me too much. In this case it was to disambiguate the context being access key rather than dict key.
  • 1
    5y
    @SortOfTested Yeah, totally get that, but the smart thing to do in that case (IMHO) is to still accept the old key with a warning. Or heck, *don't* accept it and print out a warning saying you've used the wrong name. That'd mean I could find the problem with 5 seconds of debugging rather than hours...
  • 1
    5y
    @AlmondSauce
    Inside knowledge:

    The sdk clients are code gen'd from metadata. For better or worse.
  • 0
    5y
    @SortOfTested That doesn't surprise me at all.
  • 0
    5y
    Sometimes changes seem unnecessary or illogical from a user POV but make sense from a developer POV
  • 0
    5y
    @nicofee I am a developer. I understand why they may have wanted to change that wording, but there's little to know excuse for excluding at least a warning.
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment