Download the PHP package dereuromark/cakephp-hashid without Composer
On this page you can find all versions of the php package dereuromark/cakephp-hashid. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download dereuromark/cakephp-hashid
More information about dereuromark/cakephp-hashid
Files in dereuromark/cakephp-hashid
Package cakephp-hashid
Short Description A CakePHP plugin to allow using hashids instead of numeric primary keys.
License MIT
Homepage https://github.com/dereuromark/cakephp-hashid
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 cakephp-hashid
Hashid Plugin for CakePHP
Exposes hashids as drop-in replacement for your numeric primary keys.
DEPRECATED This plugin is deprecated in favor of the more robust and future proof solution through exposing a dedicated field. See Expose plugin.
A CakePHP plugin to
- cloak the actual numeric primary key behind the record (assuming you use a non public salt) for URLs, APIs and alike
- build short unique IDs (Even PHP_INT_MAX
2.147.483.647becomeslXQAALgfor example, solength <= 7for the hashid)
This branch is for use with CakePHP 3.6+. See version map for details.
Why hashids?
- They are super short, especially for the URL
- They are lightweight and fast. They work on the fly and require no table fields, no code changes. No overhead involved except for enabling the behavior.
- You do not lose sorting capability as with UUIDs.
- You can use hashids if you do not want to expose your database ids to the user - while not compromising speed - as a balance trait-off.
Why not UUIDS?
- UUIDs can be up to 200x slower with growing DB tables, complex or heavy joins and especially with CakePHP default char(36). But even with the recommended binary(16) it would not be ideal.
- UUIDS often times completely replace the primary key, making it impossible to sort anymore on those records. This is especially problematic with data that gets inserted at the same time (same datetime for created).
- UUIDS are often used to just cloak the numeric primary keys visibility of how much gets inserted over time. But that is not what they should be used for. If you want to synch data across DBs, then they are useful. But they should not be abused for other things.
UPDATE This is actually not true if you combine both AIID and UUIDs and use UUIDs only for external lookup but keep AIID for all internal joins and operations. As such the Expose plugin fully replaces this now.
Demo
See https://sandbox3.dereuromark.de/sandbox/hashids
Setup
and
Usage
See Documentation.
Alternatives
See this nice article on a different approach that would use both -allowing "int" for internal and "uuid" for external reference.
