Download the PHP package joby/smol-uid without Composer
On this page you can find all versions of the php package joby/smol-uid. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download joby/smol-uid
More information about joby/smol-uid
Files in joby/smol-uid
Package smol-uid
Short Description A simple and lightweight time-ordered random ID library designed for human-scale applications.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package smol-uid
smolUID
A simple and lightweight time-ordered random ID library designed for human-scale applications.
What is smolUID?
smolUID is a simple, lightweight library for generating unique, time-ordered, human-readable IDs. Unlike full UUIDs, more complex enterprise-grade time-ordered IDs, or simple auto-incrementing database IDs, UIDs are:
- Human-readable: String representations as base 36 integers for more compact (10-13 characters) format for URLs, markup, etc.
- Time-ordered: Can be represented as integers or strings, and both are naturally sortable by rough creation time
- URL-safe: No special characters that are hard to type or need encoding in URLs
- Privacy-conscious: Can drop optional amounts of timestamp precision to avoid leaking exact creation times
- Ergonomic: Strings can be easily converted from the concise format back into the underlying integer, or vice versa
- Future-proof: Currently underlying integer values are 63 bits, so they fit in a signed 64-bit integer, but future versions could expand
Why smolUID?
Not every project needs guaranteed globally unique IDs or distributed systems. For many smaller applications, simpler solutions are often better:
- Human scale: Designed for applications where IDs might be seen, shared, or even typed by humans
- Simplicity: No external dependencies or complex setup
- Lightweight: Minimal overhead and easy integration (it's just an integer!)
- Chronological: Natural time-based ordering in both integer and string representations
Installation
Basic Usage
Creating a new UID
UID versions
| Version | Time resolution | Random bits | String length | Availability |
|---|---|---|---|---|
| 0 | N/A (no time data) | 58 | 13 | ~288 quadrillion |
| 1.0 | 1 second | 11 | 10 | ~1.4 billion/day |
| 1.1 | ~4.25 minutes | 19 | 10 | ~1.4 billion/day |
| 1.2 | ~18 hours | 27 | 10 | ~1.4 billion/day |
| 1.3 | ~3 days | 29 | 10 | ~1.4 billion/day |
| 1.4 | ~12 days | 31 | 10 | ~1.4 billion/day |
Getting the string representation
Getting the underlying integer
Checking equality
Advanced Usage
Getting the underlying parts
Using with databases
UIDs can be stored in your database as either strings or integers:
Deterministic generation
UIDs can also be generated deterministically if you want to use them in a manner similar to a hash. In this case they are produced as version 0 UIDs with no time data, and their random data is produced by truncating a sha256 hmac or simple hash of the provided string.
Garbage collection
In long-running scripts that work with large numbers of different UIDs in a single run (think at least hundreds of thousands, if not millions), you may want to garbage-collect the internal cache periodically. This will clear out weak cache references to objects that have been garbage-collected by PHP.
Running garbage collection just takes running UID::garbageCollect()
How It Works
Each UID consists of a single integer value with three parts:
- 4-bit version identifier in the least significant bits, from which the other two parts' lengths are determined
- 0 or more bits of random data
- 0 or more bits of time data in the most significant bits, with varying amounts of precision dropped by truncating least significant bits of the current time
The combination is encoded in base-36 (alphanumeric) when a string representation is required, but can also be stored as an integer. All current versions are at most 63 bits long, allowing them to fit in a normal 64-bit signed integer. This means you can work with their underlying values easily and efficiently in almost any environment, with no special handling.
Future versions may expand to larger bit sizes, but for now the goal is to fit in a single signed integer for maximum compatibility and simplicity.
Limitations
- Not designed or suitable for distributed systems requiring guaranteed global uniqueness
- Time ordering may be varying levels of approximate due to the dropped precision bits
- No built-in collision detection (though collisions are extremely unlikely at human scale applications)
