IllicoDB3 : The New Features

As I mentioned in a previous article, IllicoDB3 has evolved significantly, and part of its evolution stems from modifications to DB structures or, more precisely, the possibilities for structural modifications. There are also many new field types, allowing for better-structured, increasingly refined, and policed data, ensuring that integrity checks can be performed in a standardized manner on each of them.

One of the modifications we've made to IllicoDB3 concerns the integration of templates (a series of fields that can be incorporated across tables), the integration of definitions that can be applied from field to field, and the ability to extend a table under a new name (for example, extending an "invoices" table to an "offers" table, an existing table to which we may wish to add fields), and so on.

Furthermore, to further facilitate the creation of DB structures, a new createExt() method has been developed, replacing the create() method, which has recently become obsolete but remains available for backward compatibility. Note that the new createExt() method allows for many more operations to be performed much more simply, which is no small advantage: the simpler and more powerful, the better.

All these modifications have resulted in changes that had to be made to various IllicoDB3 methods, such as the readStructure() method, but also the document() method, which is precisely my topic of the day: DB documentation in a fraction of a second!

Having also detected the need to traverse a table in the order of its master index, we implemented a new class, IllicoDB3Index, which allows, among other things, to traverse a table according to the index sequence. Awesome!

As previously announced, the new features in IllicoDB3 owe much to Quitus, our mini Business suite. It's by facing specific difficulties or challenges in Quitus that new functionalities have been revealed in IllicoDB3. It's ALWAYS like this: reality imposes itself and leads us down paths that were hardly envisaged at the start, or if they were, they weren't prioritized. This isn't a lack of analysis or planning. It's the ? that escapes us and the ? of the ? that are its impacts. All of this often leads to a doubling of initial budgets, which we must consider as a present or deferred problem, particularly when we can't promote to production what has been developed. The person responsible for a Digital Transformation will worry about this, wanting to reap profits, even if they're smaller, as quickly as possible to offset costs, and wishing to be able to start depreciation as soon as possible.

Let's return to Quitus and IllicoDB3. Quitus has enriched its data model. You may recall that we hinted, for Quitus, that we would continue the development of this small Business Suite, a nano ERP, with two additional modules: documents and expense reports. It's these modules, and others, that are driving IllicoDB3 forward. To be complete and exhaustive, I should cover both aspects in concert, Quitus and IllicoDB3.

For now, let's focus on the document() method of a table.

Document()

It would require copying too much code to bring you up to speed on the structural changes in Quitus: I've made use of definitions, templates, extensions... as well as new types of fields. I've introduced a table of countries (pre-filled), a glossary (pre-filled... but which you can evolve as you wish -- this will actually be an independent module in Quitus), and so many things that it's difficult for me to remember everything. Today, with article #12, I'm going to gather all the test code and the IllicoDB3 code so that you can continue the adventure with this rather unique database.

Here's the test code that I used:

if ( true )     /* Test the document() method of IllicoDB3 */
{
    echo "<h2>Document DB</h2>";

    $DBName = 'Quitus';
    $folder = '/home/vaesoli/central-catalog';

    $oDB = new IllicoDB3();

    if ( $success = $oDB->open( $DBName,$folder ) )
    {
        $oDB->document( $docFile = v::FIL_RealPath( v::FIL_AddBS( __DIR__ ) . "{$DBName}.db-documentation.html" ) );

        if ( is_file( $docFile ) )
        {
            include_once( $docFile );
        }

    }   /* if ( $success = $oDB->open( $DBName,$folder ) ) */
    //echo "<p>LINE: <b>" . __LINE__ . "</b> - Perf: ",number_format( $t2-$t1,6,',', '.' )," sec to create the Quitus DB</p>\n";
    echo "<hr />";
}        

Damn simple, isn't it? You know what the perf test says?

Perf: 0,031512 sec to generate the documentation of the Quitus DB        

31 ms to generate the doc !

Conclusion

New modules in Quitus, confrontation with real-world situations, new requirements in IllicoDB3... we have reviewed all of this and focused on documenting a database. I'd like to bring to your attention that the notes have multiplied in the Parking Lot, which suggests new modifications for the future. Take heed!

Ah ... and here's the best ... the code!

Code included in the article (link to https://www.trql.fm/test.illicodb3.code-of-article12.zip) : test.illicodb3.code-of-article12.zip

Previous article - Next article