Livebase cloudlets configured with a custom URL have been always reachable, while cloudlets with a standard URL (hs<n>.fhoster.com) might still be reachable only via their IP address.

I apologize for the inconvience, and please feel free to contact me on skype (a.leonforte) or twitter (leonforte) for any request or need. The situation should be back to normal by tonight. More info in the next ours.

TechCrunch Italy will gather some of the most recognised leaders and innovators of the technology and media industries in Italy, Europe and the US to give a unique insight into the big changes and trends happening in the world right now.

At stand 35 we’ll show live the latest version 2.10 of the Livebase platform, the only model-driven Application PaaS platform conceived to create Enterprise database applications (and the REST API to access them) on-the fly. More on the event at www.techcrunch-italy.com.

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.

Come visit us!

We’ll be at SMAU Business Padova (stand C28) to show “live” the latest release 2.8 of the Livebase platform.

Find out how quickly and easily even non-programmers can create, deploy and manage robust, enterprise-grade databases in the cloud.

Struggling with structured data “lost” and scattered into a number of spreadsheets across your company? Bring some of these files with you at the event: our staff will be happy to show you in real-time how to import them into a secure, custom and cloud-based information system.

Register now to get your free pass.
Filed under: News ]]> http://blog.fhoster.com/2012/04/16/experience-livebase-2-8-at-smau-business-padova/feed/ 0 livebase logo.fhoster at fhoster roll-up Template Grande formato http://blog.fhoster.com/2012/03/07/livebase-2-8-relased/ http://blog.fhoster.com/2012/03/07/livebase-2-8-relased/#comments Wed, 07 Mar 2012 17:48:40 +0000 Antonio Leonforte http://blog.fhoster.com/?p=372 ]]> I’m proud to announce that version 2.8 of the Livebase platform has been released and is now in production, featuring a number of improvements both in the modeling environment and in generated applications. We also switched to MySQL 5.5 on all servers (including the hosting infrastructure) and we have fixed some bugs in the functionality to import an Excel file into a Cloudlet.

Developers who want their cloudlets to take advantage of the new features of Livebase 2.8 just need to login and press the upgrade button now available on each cloudlet. The upgrade process is automatic and will regenerate all the applications running on the cloudlet while preserving existing data.

Improvements in generated applications

Native MS Excel connectivity

Cloudlet members (i.e. end-users) can now access their cloudlets from Microsoft Excel and download data right into their Excel sheets. All they have to do is creating a Web Query within Excel (command available under the “Data” tab) pointing to the same URL of the cloudlet followed by the “/rest” postfix. Excel will ask for username/password of an existing cloudlet member, and will apply all the filters and security restrictions associated to the profile of that member.

Excel can be also configured to update the data periodically and automatically. With Web Query connectivity, cloudlet members can get the best from both worlds: safe data management with strong data-quality controls (via Livebase) and total control over statistics, calculations, pivot tables and charts (via Excel).

Localization

Livebase developers can now easily model applications that change the language of their user interface according to the language of the user who logs in. The Livebase Designer allows to define language-specific strings for each text element in the generated GUI, and also the platform can now generate warnings and error messages according to the end-user language settings. Additional languages will be supported in the near future (French, German, Spanish, Portuguese, Russian).

Custom number formats

End-users of generated applications can now be configured with specific preferences for number formats: the characters to be used as thousands and decimal digits separator, and whether thousands separators should be used by default or not.

Iconization and relocation of major commands

Main commands to Edit, Save and Cancel changes are on the top-right corner of the form, and they have big icons that highlight on mouse-over. Other commands used less frequently (Print and Refresh) are on the top left of the form and have smaller icons. We have also improved learnabilty by enforcing a consistent behavior for the Save button. In fact, the Save button was previously used in two very different contexts: when confirming changes on a part object (which only happens in memory because changes might still be cancelled for the whole object) and when confirming changes on an entire, top-level whole objects (which is permanent and happens on disk). The command to confirm changes on part objects now appears as a simple Ok button, and the Save button is now used only for actual (on-disk) database transactions.

New option for rendering associations

Since version 2.7 Livebase allows to very easily choose how to manage associations in the user interface of generated applications. Associations with a “to-one” cardinality, can be represented as a dropdown menu, as a set of radio buttons, etc., while associations with a “to-many” cardinality can be represented as a table with add/remove buttons, as a set of checkboxes, etc.

In Livebase 2.8 is now available a new representation for “to many” associations: it consists of a dynamic set of dropdown menus and it’s perfect when the user has to choose a small number of associated objects from a set of candidates approx. between 20 and 200.

Non-aggregated PieChart and BarChart reports

Modelers previously had to specify an attribute to group-by when creating a Pie or a Bar chart. This limitation has been removed in Livebase 2.8, so it is now possible to get charts where each pie-slice (or each bar) represents an individual object in the database.

Improvements in modeling

and administration dashboard

Interactive tutorial

We hope that new customers will enjoy the interactive tutorial which now starts automatically the first time they log in. The tutorial guides the customer step-by-step in the creation of its first database application. The tutorial will be improved in the next release of the platform, but it’s already pretty useful, just make sure to execute exactly the suggested steps.

Engines in  Library now editable

Previously engine models could be edited only within a non-running Cloudlet, which was unnecessarily restrictive. With Livebase 2.8 modelers can now create and edit engines in the Library, and stop the target Cloudlet just for the time required to install the new engine.

Livebase lets you draw conceptual data models (as UML diagrams), and turns them into custom, powerful information systems with a rich AJAX user interface and a dedicated MySQL database. Information systems are deployed by default on our cost-effective hosting infrastructure (based in Germany) or (as a premium option) on third-party infrastructures.

Starting from November 7th every Livebase account can be individually configured so that its databases and its applications are automatically and transparently deployed on a dedicated virtual server of the IBM SmartCloud Enterprise infrastructure.
In order to make your Livebase account deploy on the IBM Cloud just send us an email specifying which kind of virtual server you need (Copper, Bronze, Silver or Gold). We will reserve the virtual server for you and we’ll connect it to your Livebase account. The extra cost of the virtual server will be added to your Livebase bill.

By choosing the IBM SmartCloud deployment option, you’ll get a 99.9% SLA for all your Livebase applications, and the possibility to install additional custom software on your dedicated hosting server (e.g. Pentaho), directly accessing the databases managed by your Livebase applications.

The challenge

One of our customers managing a complex clinical database (with about 60 classes and almost 100 database tables) has modeled the main Patient class with dozens of derived attributes, i.e. attributes retrieving data from other classes through a query.

To make things worse, many of the Patient’s derived attributes are retrieved from classes connected to Patient class only indirectly, via long paths traversing several model associations, including many-to-many ones.

Apparently, our customer enjoyed the possibility to enrich the Patient class with additional derived “query” attributes (such as average blood parameters across exams) by just dragging attributes from other classes of the model onto the Patient class.

As a consequence, the query generated by Livebase for retrieving the patients included an impressive number of chained joins and grouping operators (avg, std, sum, count…). And no Relational DBMS likes this kind of queries, MySQL making no exception.

In fact, despite all the optimization techniques applied and all the indexes created by Livebase on the database, the query generated by the platform was quite slow as soon as the set of patients to retrieve was larger than a few thousands.

The strategy

After some experiments with views and temporary tables, we started working on a technique for breaking down the original query into multiple (simpler) sub-queries that could be executed in parallel more efficiently, and for recombining the results in memory.

The idea behind this technique is to execute a different sub-query to retrieve a subset of the patient’s derived attributes (i.e. a subset of the columns of the original recordset) connected through the same path over the data-model (i.e. retrievable via the same chain of relational joins over the database).

The main problem with this technique is how to split/replicate the original WHERE clause into the sub-queries. What if the original WHERE clause contains a condition based on derived attributes retrieved by different sub-queries?

After two weeks spent analyzing the problem and one week of prototyping, we ended up with a sophisticated algorithm for splitting the original query according to the individual conditions in the WHERE clause, and to the chain of joins required to retrieve each derived attribute.

The results

Retrieving nine thousands patients (with all their derived attributes) took about 40 seconds with the old single-query approach. Splitting the original query into multiple simpler sub-queries and combining their results in memory took about 2 seconds. A staggering 20x improvement.

Although such a dramatic performance improvement can be expected only on applications performing really complex queries, we believe that average Livebase applications with a smaller number of derived attributes will still provide sensibly better performances and better scalability over large datasets.

What’s next

The parallel sub-query technique will be adopted whenever applicable by all the applications generated by the next version of the Livebase platform, which will be released as soon testing will be completed (probably two weeks).

Improved concurrency control on bidirectional associations.

Livebase allows very easily to create applications with many-to-many associations that can be edited on both sides. For instance, you can have an Employee class, a Project class, and a many-to-many association between these classes: if the association is bidirectional, users can concurrently add/remove Projects from any given Employee and also add/remove Employees from any given Project. This means, for instance, that an Employee can be concurrently modified directly (by editing it) and indirectly (by removing it from any of the Projects he’s associated with).

Livebase also allows to define min and max cardinality constraints on both sides of each association (e.g. an Employee can work on no more than three Projects, and a Project must involve at least one and at most ten Employees). Enforcing cardinality constraints efficiently on bidirectional associations, under heavy concurrency conditions, requires a very sophisticated logic.

Upon user’s suggestion, some parts of the application-level locking system (originally designed with a pessimistic approach) have been refactored with an optimistic approach, which should deliver an higher degree of concurrency with a small risk of transactions rejection.

Improved objects-counting query generation

When a user wants to list all the objects of a given class (e.g. all the Orders), Livebase applications count first the number of objects visible to that user according to the database-partitioning rules defined on the specific application (e.g. show only Orders approved in the same month) and also according to the grants associated to the user’s role (e.g. show only Orders issued to the department the user belongs to). The preliminary query used to retrieve this preliminary count from the database is now optimized whenever possible (less joins) in order to be faster.

XML data representation added to the REST APIs

Every application generated by Livebase comes with a complete REST API to access data programmatically (only GET methods are currently supplied, PUT, POST and DELETE methods will be supported by the end of September). Up to now only the JSON format was available with the REST API to represent objects. With this release, XML is also available. The documentation on the web site will be updated as soon as possible with all the technical details on how to use the new XML representation.

New skin for the user interface of generated applications

In the process of creating a skinning framework for the applications generated by Livebase (allowing end-users to select their preferred skin at run-time) we have just released the first skin, which we believe is much nicer than the standard one provided by the GWT framework. Hope you like it!.