Update to ID lengths

[Greg Brockman]

We'll soon be increasing the length of most IDs returned by the Stripe
API (to around 30 characters). We have deliberately never published
the length of these IDs, but we wanted to let people know in case
they're relying on the existing length. We may vary the length of IDs
in the future, but you can safely assume they'll never exceed 255
characters.

On timeline, we plan to increase the ID length for newly-created
accounts no earlier than Monday, with existing accounts seeing
increased ID length no earlier than Wednesday. (We may end up rolling
out more gradually than that.)

As well, we've added a list of the categories of changes that we
consider to be backwards compatible, and may make in the future
without advance notice:

https://stripe.com/docs/upgrades#what-changes-does-stripe-consider-to-be-backwards-compatible

Let me know if you have any questions!

- gdb

[Alexey Panteleev]

Please don't shorten the ids, we've implemented multi-plan support by encoding multiple ids into one Stripe plan id so we need some length there.

-Alexey

> --
> You received this message because you are subscribed to the Google Groups "Stripe API Announcements and Discussion" group.
> To post to this group, send email to api-d...@lists.stripe.com.
> Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.
>
>

[Greg Brockman]

Hey Alexey,

Do you need IDs of over 255 characters? Note that we're not changing
any behavior for user-specified IDs here, just IDs we generate. (In
the future, we may start enforcing a limit for those, but we'd
consider that to be a backwards-incompatible change and would use our
versioning scheme to avoid breaking you.)

- gdb

[jay...@nsfwcorp.com]

On Friday, August 9, 2013 6:12:01 PM UTC+1, Greg Brockman wrote:

 

We'll soon be increasing the length of most IDs returned by the Stripe
API (to around 30 characters). We have deliberately never published
the length of these IDs, but we wanted to let people know in case
they're relying on the existing length. We may vary the length of IDs
in the future, but you can safely assume they'll never exceed 255
characters.

Can some sort of statement (and hence guarantee) of maximum length be added to the API documentation? We need to be able to store Stripe IDs at our end (customers, charges and invoices, but I can't guarantee other types will not arise), and although it sounds like we won't be affected this time, the very short timeline presented would have caused us considerable pain had it been an issue. Future Stripe clients might not be so lucky.

Best,

James

[Alexey Panteleev]

255 is good enough. our ids are shorter than that right now, but it's good to know the limit.

[Michael Sander]

I'm sure you've considered this, but many of us store customer IDs in app engine's StringProperty field, which can only store 500 characters. So any increase above that amount would break plenty of apps.

https://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#StringProperty

[Greg Brockman]

> Can some sort of statement (and hence guarantee) of maximum length be added
> to the API documentation? We need to be able to store Stripe IDs at our end
> (customers, charges and invoices, but I can't guarantee other types will not
> arise), and although it sounds like we won't be affected this time, the very
> short timeline presented would have caused us considerable pain had it been
> an issue. Future Stripe clients might not be so lucky.

Yes, just added a statement to the same page [1].

Note we chose a short timeline in the first place because we believed
the number of users likely to be affected to be very small. If anyone
needs more time to make the change, we'd be happy to extend the
timeline for their account.

- gdb

[1] https://stripe.com/docs/upgrades#what-changes-does-stripe-consider-to-be-backwards-compatible

[Greg Brockman]

> I'm sure you've considered this, but many of us store customer IDs in app
> engine's StringProperty field, which can only store 500 characters. So any
> increase above that amount would break plenty of apps.
> https://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#StringProperty

Yep, to be clear, we'll never in the future return IDs of over 255 characters.

[Larry Philps]

Hi Greg,

I just followed the link to read the new doc, and for MySQL you recommended VARCHAR(255) columns to hold ids.

However, it appears to me, in spite of the fact that the ids are "opaque" :-), that they contain both upper and lower case letters? Since the MySQL VARCHAR type is case independent, Would it make more sense to use VARBINARY(255) to hold the ids so that MySQL will treat, for example, cus_a0000000000000 and cus_A0000000000000 as different ids?  Might we ever see two ids that differ only by the case of the letters in them?

Thanks,

Larry

[Patrick Altman]

I have 6 accounts that I can think of using django-stripe-payments, some Eldarion's own sites, and some sites of our clients (some of which the engagement is already over) that this will affect per:

https://github.com/eldarion/django-stripe-payments/blob/master/payments/models.py#L56

Furthermore, anyone who has used this package is going to be affected by this and will need an update. The fix and update is very quick an easy to make to DSP, however, it will take some time to update all affected sites. 

Is there anyway you can only apply this change on new accounts? Or at least give us a few months? I need to notify users of my open source package and I am sure they all need time. 

---

Patrick Altman

Nashville, TN

[Patrick Collison]

Well, VARCHAR isn't exactly case insensitive -- it depends on your
collation. You're right, though, that the default is case insensitive.
Given that it's case-preserving regardless, this should only matter if
we happen to return two IDs separated only by case, which is very
improbable. Still, we should update our recommendation to use
case-sensitive collation.

But, having thought about this issue, we're now considering
guaranteeing that our IDs will be [a-z0-9] so that people can't make
errors of this sort. We'll follow up shortly.

[Greg Brockman]

Hey Patrick,

We're only increasing the ID length to around 30 characters at the
moment — I'm happy to commit to keeping the length under 50 characters
for the next 6 months. (I'd be surprised if we actually went up to 50
characters in the future, but we don't want to make promises we can't
absolutely know we can keep.) Given that, do you still want extra
time?

- gdb

[Patrick Altman]

Awesome. Ill upgrade to 255 now but 6 months will be e ought time to cover just about everyone I think. Ill include release notes with details from this thread to apprise my users. Thanks!

---
Patrick Altman
Nashville, TN

[Patrick Collison]

To come back to this: we've decided not to change the case of IDs for
now -- i.e., they'll remain mixed-case -- but we plan to revisit
things again and generally take a look at how our longer IDs are
working out in a few weeks.

The chance that the current state of affairs (with both upper- and
lower-case chars) will cause issues even if you don't have
case-sensitive collation enabled is basically 0, but I'd suggest
people using VARCHAR columns also specify COLLATE utf8_bin. We've
updated the docs to recommend that too.

Thanks for the heads up!

Patrick