Version 0.9.2

This release brings some improvements to the way ids work. In short, id generation is now less likely to produce collisions, and it uses base58 encoding to result in shorter ids (compared to the base36 encoding previously used for some components) which are also easier for humans to use.

In addition, there are also some minor breaking changes: some exported structs and methods that have to do with ids have been renamed. See the full changelog below for more information.

Decreased Likelihood of Collisions

Ids generated by Zoom are now much less likely to result in collisions. Whereas the old implementation used only two components (unix time and a generated sequence of 16 characters) ids generated with the new implementation now consist of 4 components:

1. The current UTC unix time with second precision
2. An atomic counter which is always 4 characters long and cycles
   through the range of 0 to 11,316,495
3. A unique hardware identifier based on the MAC address of the
   current machine
4. A pseudo-randomly generated sequence of 6 characters

Collisions are still possible, but are incredibly unlikely. In order for a collision to occur, all of the following would need to happen:

1. On a single machine (or between machines with MAC addresses which result in the same crc32 checksum), at least 11,316,496 models would need to be saved within a time period of one second. If this does not happen, collisions are impossible.
2. In addition, one or more of the models created during this time period would need to result in a collision of the randomly generated 6 base58 characters. This character sequence is produced via the crypto/rand package, which reads from dev/urandom when possible. There are 58^6 = 38,068,692,544 possible values, so collisions are extremely unlikely.

Performance Impact

The function which generates ids is roughly 2-2.4x slower, but the effect is largely negligible compared to network latency and other performance factors. The trade-off is one that I believe makes sense, as in some applications id collisions could be really harmful.

Breaking Changes

The embeddable struct DefaultData has been renamed to RandomId to better reflect its behavior. This also opens the door for other id implementations to be included in the future (e.g. AutoIncrementedId).

The Id field of RandomId is now exported. The motivation for this change was to make models with an embedded RandomId more easily serializable. For example, with the old implementation, the id field was not included if you serialized a model to json.

The methods of the Model interface have been renamed to ModelId and SetModelId. This is more idiomatic in go and was necessitated by the fact that the Id field of RandomId is now exported.

Id generation now happens the first time you call ModelId as opposed to during the Save method. The reason for this change was to allow for other id implementations to be easily dropped in. Without this behavior, we would need to do something special during the Save method depending on which type of struct was embedded, which adds undesirable complexity and makes custom implementations nearly impossible. This way, the current implementation, any future implementations provided by Zoom, and any custom implementations all work the same way.

Ids generated using the old implementation will still work fine, so changes related to the way ids are generated are fully backwards-compatible.

Full Changelog

• DefaultData has been renamed to RandomId.
• The Id field of RandomId is now exported.
• The methods of the Model interface have been renamed to ModelId and SetModelId.
• Id generation is now less likely to produce collisions.
• Id generation now happens the first time you call ModelId as opposed to during the Save method.
• Tests now catch a previously uncaught error when calling the Init function.
• Generated ids now use base58 encoding.