In order to use newer regions like Frankfurt, the CRUDlex Amazon S3 FileProcessor got a small update with the requirement of a newer version of the aws/aws-sdk-php. As this required a region parameter in the constructor, the small project changed to SemVer.
- Updated the aws/aws-sdk-php to ~3.19 and so requiring the region as first parameter in the constructor
- Relaxed a bit the required CRUDlex version
With 218 commits, this release of CRUDlex 0.10.0 is a bit bigger.
Most notable: Finally, many-to-many relationship landed in form of the many data type.
Also the versioning switched to SemVer. As the 1.0.0 isn’t released yet, the project is still free to change the API in a vivid way contrary to the small version jumps.
And so it does with this release! I’m pointing for example towards the switch to Silex 2.0. Each not backward compatible change is marked with “Attention” in the changelog.
But also the usability has improved a bit with the introduction of the validation of the entity definition YAML file.
Beside that, some refactoring and consolidation of the YAML format and the API has happened.
Read on to see the full changelog of all CRUDlex projects for details!
94 commits later, CRUDlex 0.9.10 got released!
This release comes with a big cleanup within the API making it not backward compatible, so take care!
The main new thing beside the code itself is the new documentation which is based on Sphinx now. It combines the manual and the API documentation at a single place.
A lot of fixes and cleanup happened along with some smaller new features. Mainly noted the switch to flatpickr as datetime picker and the support for RTL languages. Some events within the file handling have been added as well. And also the SimpleFilesystemFileProcessor is more configurable now.
The input validation is now handed over to the shiny new library Valdi which got developed for this project. But more on that later.
Here and there some IDs and classes for the CSS and the release is done.
Here is the full changelog:
- Attention: Removed the prefix “CRUD” from all classes as they live in their own namespace anyway
- Attention: The data types “int” and “bool” got renamed to “integer” and “boolean”
- Attention, API changes:
- CRUDlex\Data -> CRUDlex\AbstractData
- EntityDefinition::getInitialSortAscending() -> EntityDefinition::isInitialSortAscending()
- ServiceProvider::getMangeI18N() -> ServiceProvider::isManagingI18n()
- Show-Page: The id “crudEntityShowTable” is now a class
- CRUDlex\EntityValidator changed its return structure to the one of Valdi: http://philiplb.github.io/Valdi/docs/html/0.9.0/manual/gettingstarted.html#validation
- The date and datetime fields changed moved their classes to the input fields and changed their names to “crudDate” and “crudDateTime”
- Attention: Fixed a security issue in the static file provider
- Changed the entity validation to https://github.com/philiplb/Valdi
- Changed the date and date time pickers to https://github.com/chmln/flatpickr
- Replaced the markdown manual and the APIGen documentation with an unified Sphinx version
- Added RTL support in the i18n system
- Added file handling events
- Made a base path configurable for the SimpleFilesystemFileProcessor
- The ServiceProvider uses now static instantiation instead of calling his own class making it easier to override
- Added some more IDs and classes in the HTML to be more tweakable
- Fixed a crash if the table name of an entity is a MySQL keyword
- Fixed a crash if the field name of an entity is a MySQL keyword
- Fixed a crash if the sort field name of an entity is a MySQL keyword
- Fixed a crash if non required reference fields where not given
- Fixed a crash if referenced entities got soft deleted by a third party
- Fixed the sort order being properly handled in the pagination buttons now
- Fixed and refactored a lot of things revealed by static code analysis
Again, quick, Flynn is a self hosted platform as a service which is easy to setup and operate.
It stores the files of applications to deploy (along all releases for rollbacks) within a Flynn internal application called blobstore. It is a data store for large files and the underlying implementation uses the Large Object support of PostgreSQL.
If you have an application of the size like 100MB, which is quite common with dependencies, this release history can grow quickly and your available hard drive space on your cluster servers can shrink in the same speed.
And your backups grows with the same speed as well. It takes longer to backup and longer to restore which increases your downtime in case.
With the release of the stable version v20160624.1, Flynn gained the ability to use Amazon S3 as storage system for the blobs solving the mentioned problems.
This posting shows you how to migrate a Flynn cluster to S3.