PHP Classes

PHP Create UUID v4 type: A custom Doctrine data type for UUID v4 values

Recommend this page to a friend!
  Info   Documentation   View files Files   Install with Composer Install with Composer   Download Download   Reputation   Support forum   Blog    
Ratings Unique User Downloads Download Rankings
Not yet rated by the usersTotal: 83 All time: 10,060 This week: 488Up
Version License PHP version Categories
uuid64type 1.0.0BSD License7.3Databases, Data types, PHP 7, Traits
Description 

Author

This package provides a custom Doctrine data type for UUID v4 values.

It provides a means to create values that represent universally unique identifier strings according the version 4 of the UUID specification.

The package can be used in applications that use Doctrine ORM so it can store the generated values in data objects as primary keys.

Innovation Award
PHP Programming Innovation award nominee
March 2020
Number 4
UUID are values that can be used to uniquely represent an object eventually stored in a database, in a way that the two different objects will not have the same UUID value.

This package provides means to generate UUID values according to the version 4 of the UUID specification, so it can easily be used in applications that use the Doctrine ORM tool.

Manuel Lemos
Picture of Michael Cummings
  Performance   Level  
Name: Michael Cummings <contact>
Classes: 9 packages by
Country: United States United States
Age: ???
All time rank: 1895263 in United States United States
Week rank: 192 Up22 in United States United States Up
Innovation award
Innovation award
Nominee: 7x

Winner: 1x

Documentation

Uuid64Type

A custom Doctrine datatype for UUIDv4 values in database tables that offers a more compact format that can be useful for primary key columns. Also, includes helper traits to make integration easier.

Installation

Use composer to install from packagist.

composer require dragonrun1/uuid64type

Usage

For an example of integrating with Doctrine cli configuration have a look at:

config/example-cli-config.php

For examples of using Uuid64Type in a Doctrine project see my related project on github:

person_db_skeleton

Look at the config/cli-config.php for how to register the custom type in Doctrine.

See any of the src/Model/Entities/* table class files for using the helper traits etc.

Why make this project?

If this project was just another UUID v4 (random) library there would be little point as there are already several fine ones out there for PHP, but where they just do UUIDs this library tries to solve a limitation in common database designs as well. The limitation is how database engines typically generate their IDs which I'll detail next.

Database Engine Limitation

Database engines be they MySQL, PostgreSQL, SQLite, or any other all have some way to generate sequences for ID columns. How they do it is nearly as varies as the engines themselves since ID generation falls outside of the existing SQL standards, but the end result is generally the same in that you end up with a simple auto-incrementing integer sequence. So where does the limitation come in and how is it bad? Two words: auto-incrementing and sequence. Add two more words: bad actors. Combining these four words and some of you may have started see the possible problems. Next I'll show why combining a bad actor with the first two words can become an issue.

The issue with auto-incrementing sequences

First a question for you. How often have you directly exposed a database table ID in a web form on the Internet? If you are like most developers including me I think we have all done this without thinking about it more than once. We may have made it a hidden field but, it's plain to see for anyone looking directly at the page code. Let's now think about auto-incrementing sequence and what it can tell us about the underlying DB table. The universal default for the sequences is they start at 1 and increase by 1 for each row added to the table. By causing the site to add a row to the table and looking at that new row we can make a good guess to how many rows there are in it and by add a second row make a good guess at how fast it is growing. How is that information useful? What if the table holds users accounts, and it's their account ID? Now they have some idea how many actual user accounts they can get in a data breach or are available to be attacked. Say they get just a list of user names, and the IDs which ones should they attack first? I'd attack the first accounts made as they are likely to be admin or test accounts with greater access. I'm sure you can think of many other ways that simple incremental sequences could be attacked that you probably never thought of before I pointed out the risks.

Custom base 64 encoding of UUID v4 (random).

Expected use will be in Doctrine entities instead of using auto-increment IDs.

A UUID is 128-bits long in binary and, most programming language can only support it in some kind of string or integer array format. Most commonly binary strings will be used for compactness where strings can contain (nul) chars. This format normally isn't seem except in functions were the UUID is being created as it's hard for programmers to visualize it easily. The normal formatted string version with 36 characters or as a hexadecimal string with 32 characters are much more commonly used. Both of these formats trade off two times or more memory usage to make them easier to work with. By using a base 64 encoding it increases the memory usage by less than 40 percent (22 chars) over a binary string (16 chars).

So in summary these are the benefits to using this custom base 64 encoded format:

* Database compatible - Can be directly stored in any of the following field

types: VARCHAR, CHAR, BINARY, etc.

* URL compatible - Doesn't contain any chars that require special

escaping in URLs.

* HTML compatible - Doesn't include any special chars that need to be escaped

when used in html forms or tag property values. HTML 5 relaxed the rule
requiring all ID property values to start with a letter.

* More Human readable - Since base 64 is shorter that other formats most

people find it easier to read.

* The best memory to speed trade-off - The binary string takes up the

least memory but, it needs to be converted to and from other formats
when using it in URLs etc. which can cause un-needed server load
issues. The normal and hexadecimal forms are both longer which adds
to both memory and server load issues. The custom format hits the sweet spot
where no conversions aren't required and, it doesn't use a lot of extra
space either.

Contributing

Please note that this project has a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Please make sure to update or add tests as appropriate.

License

BSD-3-Clause

Copyright (c) 2019 Michael Cummings. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


  Files folder image Files (13)  
File Role Description
Files folder imagebin (4 files)
Files folder imageconfig (1 file)
Files folder imagesrc (1 file, 2 directories)
Accessible without login Plain text file CODE_OF_CONDUCT.md Doc. Documentation
Accessible without login Plain text file composer.json Data Auxiliary data
Accessible without login Plain text file LICENSE Lic. License text
Accessible without login Plain text file README.md Doc. Documentation

  Files folder image Files (13)  /  bin  
File Role Description
  Accessible without login Plain text file bootstrap.php Aux. Auxiliary script
  Accessible without login Plain text file Uuid64 Data Auxiliary data
  Accessible without login Plain text file uuid64.bat Data Auxiliary data
  Plain text file Uuid64.php Class Class source

  Files folder image Files (13)  /  config  
File Role Description
  Plain text file example-cli-config.php Class Class source

  Files folder image Files (13)  /  src  
File Role Description
Files folder imageEntity (2 files)
Files folder imageType (1 file)
  Plain text file Uuid4.php Class Class source

  Files folder image Files (13)  /  src  /  Entity  
File Role Description
  Plain text file Uuid64Generator.php Class Class source
  Plain text file Uuid64Id.php Class Class source

  Files folder image Files (13)  /  src  /  Type  
File Role Description
  Plain text file Uuid64Type.php Class Class source

The PHP Classes site has supported package installation using the Composer tool since 2013, as you may verify by reading this instructions page.
Install with Composer Install with Composer
 Version Control Unique User Downloads Download Rankings  
 100%
Total:83
This week:0
All time:10,060
This week:488Up