We are very proud to announce that Livebase 2.10 has been released and is now in production, featuring a number of improvements over the last public release 2.8. The major new features include a new on-demand backup system, deferred model validation, dynamic data-type change for class attributes (with no data-loss whenever technically possible) and a powerful enanchment on unique constraints now applicable also to relation roles.
Backups on demand
Create a snapshot (image backup) of any cloudlet in seconds, with a single click. Backups are saved on our secure storage area: sort them by date or cloudlet, and restore them with a single click.
Livebase automatically performs disaster-recovery images of every cloudlet every 4 hours, and these images are stored on physically distinct servers . Livebase also allows developers to download the database of their cloudlets (as a MySQL dump or as a MS Access file) at any time. The good news is that Livebase 2.10 now also features a quick-and-easy, server-side backup option. Just open the command menu of the cloudlet you need to backup and click on the “Backup” command, which basically takes a snapshot of the cloudlet (members, applications and database) and saves it (as a compressed archive) on a special storage area safely located on a physically distinct server. To list all your backups just click on the “Backups” tab located on the top-right area of the dashboard. Each backup in the list is identified by a timestamp, a short description of its content (whatever was inside the cloudlet when the backup was created) and an optional comment provided by the developer. You can group backups by cloudlet or by date. To restore a backup, just select it from the list and press the “Restore” button at the bottom of the list: a new cloudlet will be created, identical to the one the backup was taken from. Please note that on order to restore a backup your account must have resources enough for the additional cloudlet created by the restore command.
Deferred model validation
More flexibility in editing complex models. Freely change or delete model elements: any other element depending on the changed/deleted ones is now just marked as invalid.
Until version 2.8, the Livebase designer constantly enforced formal validity in the models, while they were drawn by developers (i.e. not just on save). The rationale was to pro-actively prevent the developer to draw inconsistent models. An important drawback of such a rigid approach, however, was that when developers changed or deleted some model elements, any other element depending-on or referring-to the changed/deleted element were changed/deleted as well, automatically, to keep the model consistent in real-time. On complex models, with complex query/math derived attributes, this behavior turned out to be less than desirable. In Livebase version 2.10 the designer allows to apply changes on the model that temporarily make it inconsistent. When this happens, the designer shows a warnings and allows the developer to go through a list of the issues and fix them. If you delete an attribute, for instance, the designer in Livebase 2.10 does NOT delete all the derived attributes depending on the deleted one: it just mark them as invalid allowing you do adapt the expression behind each of them. Note, however, that it’s still not allowed to save an inconsistent model: any problem in the model must be fixed in order to save it.
Dynamic (data-preserving) attribute type change
Change the data-type of an attribute in the model of a cloudlet already in production, without losing data (some restrictions apply).
Developers can now change the data-type of an attribute whenever it makes sense (that is, when the semantics of the attribute does not change). This new feature is extremely useful when the cloudlet database already has some data that you want to keep: in this case, in fact, deleting the attribute and recreating it with the new data-type would delete the existing (populated) column in the cloudlet database, and would replace it with a new empty column. To change the type of an attribute, in the Livebase 2.10 Designer, just right-click on the attribute (in the Database schema) and select one of the target data-types in the “Change type” submenu. Please note that not all the conversions are allowed.
New “Year” data-type
The new year data-type allows a more semantically correct management of year values into Livebase applications, and a better formatting too.
All the applications generated with Livebase automatically format big numbers using the thousand separator configured for the current user (e.g. a dot for Italian users, a comma for English ones).Unfortunately this happened also with years, because they were normally modeled as integer attributes. With Livebase 2.10 developers can now take advantage of a special “Year” data-type, whose value are not formatted with the thousand-separator. Please note that only a subset of the arithmetic operators are allowed on years (e.g adding an year to another one does not make sense).
Scope of unique constraints can now be restricted
It is now possible to enforce that two offices “of the same company” cannot have the same name. The additional condition between quotes (scope restriction) is the new feature.
In Livebase 2.8, every unique constraint applied on a class had an implicit global scope, in that it was mandatorily applied on all the objects of that class. In order to provide the modeler with more flexibility, the latest version of Livebase allows to restrict the scope of the constraints to a subset of the objects based on their relationships with other objects.
To clarify this concept, let’s consider a simple model with a “Company” class related to an “Office” class via a composition, as in the picture below.
Given such model, end users are able to create companies and, within each company, to create the offices of that company. However, applying a unique constraint on the office name without restricting the constraint’s scope would always prevent the creation of two offices with the same name, even if they belong to different companies.
With Livebase 2.10 it is now possible to include in the unique constraint, along with the office “name” attribute, also the role linking the office to the company it belongs to. By doing so, the resulting applications will prevent the creation of two offices with the same name only when they belong to the same company (in other words, name collisions will not occur between offices of different companies).
More generally, Livebase 2.10 allows unique constraints to include not just class attributes but also any “whole” role (added to the constraint by default) and any association role whose max cardinality is one (to be added manually when desired.
Redundancy control on association objects
Easily prevent the creation of redundant association objects between the same pair of associated objects (e.g. the result of a match between two basket teams, or the score a student got on a university course).
Livebase does not allow to add attributes to an association (i.e. to create an “association class” in UML terms), but modelers can easily work around this limitation by turning the association into a class with all the desired attributes, and by linking such new class to the two classes that were at the end-points of the original association. This technique is known as “association reification” and is shown in the example below.
Let’s consider, for instance, the problem to track the scores that some students get at the exams they pass: a simple relation between the “Student” class and the “Course” class (as shown in the picture below) would not allow track how each student scored on each course.
In fact, “score” cannot be an attribute of the Student class (because each student has one score for each course passed) and it cannot be an attribute of Course class either (because each course is passed by many students with different scores). In essence, score should be an attribute of the association between the Student and the Course classes, but, as noted previously, Livebase does not allow to add attributes to associations.
To solve this modeling problem developers can “reificate” the association by replacing it with a class “Exam” with the score attribute, and by associating this new class to the Student and to the Course classes as shown below.
Objects of classes like Exam are often called “association objects”, in that their main purpose is to associate other objects (a student and a course, in the example) and to hold the attributes of such association (the score).
With Livebase 2.8, however, there was no way to prevent the creation of multiple association objects connecting the same pair of end-point objects. In our example, there was no way to prevent the creation of multiple exams for the same student-course pair.
With Livebase 2.10, instead, developers can now easily create on the “reificated” class a unique constraints containing just the roles linking it to the end-point classes. Back to our example, developers can now add to the Exam class a unique constraints containing just the student and the course roles, which definitely prevents the creation of multiple exams for the same student-course pair.
Automatic layout of models
Drawn a complex model and need help in arranging classes and relation? The new automatic layout algorithm sorts it out minimizing bends, relations crossings and the overall diagram area.
It is always a good practice to draw Livebase models placing semantically-related classes on the same diagram, close one another. Sometimes, however, an automatic layout facility comes handy, especially when models are not originally drawn by the developer but automatically reverse-engineered from MS Excel files.
Livebase 2.10 now features a sophisticated automatic layout facility that can rearrange your diagrams moving classes and re-routing relation lines in order to minimize crossing between relations, the total number of bends along relations and the overall area off the diagram.
Instant cloudlet stop & restart
Stopping and re-starting a cloudlet is now up to ten times faster.
The architecture of the cloudlet stop operation has been redesigned to make it much faster. In Livebase 2.8 all the applications running on the cloudlet were immediately undeployed, which required up to ten seconds. With Livebase 2.10 applications are now just configured as logically inactive, but they stay deployed just in case the cloudlet is restarted without changes in the underlying model. The entire stop and re-start process now takes a few seconds, and it also saves considerable CPU time on the hosting server,
Livetable preferences now preserved during cloudlet rebuild
When you extend a cloudlet already in production, preferences applied by cloudlet members on livetables corresponding to unchanged classes are preserved.
In Livebase 2.8 each time a cloudlet in production was modified and rebuilt, all preferences applied by members on the livetables of the generated application were reset. Such preferences include the set of hidden/visible/grouping columns, the order of the columns and their internal ordering, filters, etc. With Livebase 2.10 such preferences are preserved through the cloudlet rebuild process, with the only exception of the livetables corresponding to classes whose database-schema has changes (attributes added/deleted or attribute type changed).
REST API now supports localization for the HTML data format
Checking the results of a REST API call to a cloudlet using the HTML data format? Enjoy classes, attributes and roles names localized in the language configured for your account.
HTML is one of the data formats available from the REST API of any cloudlet, along with XML and JSON. HTML is format has been provided to support humans reading the results of each call, but in Livebase 2.8 classes, attributes and roles were reported using model identifiers rather than labels localized in the language of the account making the call. This has been fixed in Livebase 2.10. Please note that both the XML and the JSON data formats will still refer to classes, attributes and roles using the identifiers specified in the model, since those data formats are conceived to be machine readable.
REST API now supports calculation of derived attributes before commit
Need to calculate the value of a derived attribute for a given modified object before saving the object? Now you can!
Quite often the form for editing a database object has some read-only fields that are recalculated and updated automatically whenever you change some of the other fields according to some formula. In Livebase you can achieve this by using derived attributes (i.e. attributes whose value is derived – calculated – according to a formula based on other attributes) and the generated applications perform the magic automatically. In Livebase 2.8 however, it was not possible to create a client based on the REST API with a similar behavior, because there was no way to ask the server “what would be the value of this derived attribute given the values of all the other attributes” without actually saving the entire object. Now with Livebase 2.10 you can, so the end-user can see the result of the calculation and decide whether to save the object or not.