The goal behind v1.8 is to get Brimbox stable and mature. Generally databases are built and altered with great care and we want to get Brimbox to a trusted state. This is the last version which will be have global changes, and almost all planned features are now implemented. From now on the core product will change slowly and carefully.
Version 1.8 contains many new features, however, for the most part, anything coded for v1.7 will work in v1.8. Please upgrade with care, standard instructions for a safe upgrade are now included on the release page.
Here is a bulleted list of changes.
- A file datatype was implemented. Brimbox now allows files to be stored and referenced in column c47. Brimbox files are stored in the large object store, with the large object id corresponding to the Brimbox data table primary key id. There is only one large object store per database and Brimbox monopolizes it. Do not use the Brimbox file type if the large object store for the database is in use. Note: In Postgres 9.xx, large objects will be accessible only to the creator or a superuser, so the Postgres database owner may not have permission to access large objects. This should not be an issue as long as the connection string user does not change.
- A file backup download was implemented. This feature creates a backup file (extension bblo) for storing files separate from the standard backup file (extension bbdb) which stores the data, users, log, module and JSON data. In general, when using the file feature, probably a standard Postgres backup would be in order, however this feature is available if one wishes to backup the large object store in a Brimbox format.
- A document store (not JSON documents, but any standard file) was implemented on the “Setup” tab. The “Upload Documents” module is designed mainly for the storage of database documentation like would be linked on the “Home” tab. If a file is stored in the
bb-configfolder and linked on the “Home” tab with HTML an anchor it would be publicly available. This may be a security issue. Use the
$main->document($parameters)function to create a download link for a file stored in the document store which only a user with access to the database and an appropriate permission can access. There is currently no Brimbox backup for the Document Store. It is a assumed that these files would be backed up individually or with standard Postgres backup.
- A related layout structure was built. A related layout (or layouts) is a one to many relationship from a layout (or psuedo-table) to another layout, and the key which relates the two tables can be stored in columns c41 through c46. This kind of relationship is used, for instance, if you had data in layouts such as Projects, Leads, and Sales and you wanted to relate a layout with Employees to all of them. To set up a related table, click the related checkbox next to the layout on the “Set Layout Names” module and then choose the related layout on the “Set Column Names” module next to columns c41 through c46. The related key is stored with the primary column data from the related layout and the row_type, so when joining in a query invoke
ON id = bb_key(c41). This would join a layout to a related layout. To relate a layout, get the appropriate record being inserted or edited in the input tab, navigate to the record to relate (on the “Browse”, “Lookup”, or “Search” tabs) and click the “relate” link below the record.
- Update functionality was added to the “Upload Data” module. To update data, as opposed to inserting it, create a tab delimited data file with a “Link” key column and column names corresponding to the layout being updated, and populated with whatever data cells you want updated. Empty cells are ignored. The Upload Data module requires a data file that mirrors the layout.
- Postgres function names in the database were changed, a
bb_prefix was added. Old functions were not deleted so there is backward compatability. This was a simple nomenclature issue, noting that if PostGIS or something like that happened to be installed in the database, it would be nice to have Brimbox functions separated.
- Data types were all changed from
text. This is a more modern database method, and reflect current database standards. It also makes Brimbox more flexible should it be desired to do advanced or extreme customization.
- String functions no longer truncate input. By default the HTML forms allows 255 and 65536 characters in data rows, however these values can be changed, and the “Input” and “Update Data” modules will not truncate data like previous versions possibly could have.
- Optional constants had a
BB_prefix added. The core configuration constants have not changed, but from now on and retroactively optional constants will be of this form. Again this is a nomenclature issue, and was made to further organize the optional constants.