Indi Engine AI Modernizes Legacy Databases

This design allows developers to manage multiple database applications from a single instance, facilitating seamless switching between various app design projects.

"For developers, it means it's possible to work on multiple database apps from within a single Indie Engine instance as you can switch from one to another when needed and therefore Indie Engine works here as a hybrid database client evolvable into an app for every database you connect to."

It updates records simultaneously across multiple grids and forms, tracking user sessions, browser tabs, and filtering logic. Changes are delivered via WebSockets to all relevant data views.

"Another cool feature in Indie Engine is the real-time updates across the desktop style multi-window UI. So you can open multiple grids with records or multiple forms each for specific record. So if any of involved records are affected by some other user script or an SQL query, you will get the changes reflected in the relevant data views immediately."

The system includes default retention policies for hourly, daily, weekly, and monthly snapshots.

"In Indie Engine backup system is based on GitHub because GitHub allows to upload up to thousand assets to each release created for a single GitHub repository. And this means that every backup which you create can be up to 1.9 terabyte each for free."

A wrapper container is utilized for secure bash script execution, ensuring that the PHP container cannot access sensitive GitHub credentials. This architecture guarantees that the Apache container remains unaware of the GitHub token used for backup uploads, thereby enhancing overall security.

"Basically when you will do the backups... the Apache container does not know nothing about the GitHub token which is used to upload the backups on your GitHub account. So it's this is completely maintained by the wrapper container which has full access to the file system of the VPS host."

It scans the schema, extracts crucial entities and relationships, and saves this metadata as a JSON snapshot. This snapshot then serves as the foundation for preparing and importing the application design.

"Indie Engine connected to the external database scanned schema extracted the important things from there and saved it to the source meta snapshot in JSON format as you can see based on that it's prepared the app design and now that app design is being imported."

Clicking this button enables users to instantly navigate to the corresponding foreign record, streamlining data exploration within the application.

"So we set up a navigation uh for that field. So the special jump button will appear near the dropdown and on click it would be possible to jump to the corresponding foreign record."

This transition makes the grid more sensible and allows for a cleaner interface, often replacing text labels with icons in headers.

"Now let's do the main thing for uh reorganizing the grid from single single headings uh into multiple multiple level headings because that will make uh the the grid in general much more uh senseful and it will also save up the horizontal"

Indi Engine supports advanced UI features such as the row expander, which is utilized for displaying nested data efficiently. It also demonstrates custom data templating, combining elements like age with the title column to reduce redundant grid columns and enhance data presentation.

"and move some other columns to the row expander. which is a feature available for the XJS group. uh now let's uh show the age uh in the title column after a comma so that uh there will be no separate grid column for the age"

Grid chunks in Indi Engine serve as advanced field sets, enabling the embedding of grids directly within forms, such as a student details form. This configuration allows for the hiding of specific columns from the grid chunk when it is displayed as a form element, offering a more flexible and dynamic approach to form design. This approach replaces many standard form fields with more interactive and data-rich grid segments.

"And here vice versa, we hide the corresponding columns from that grid chunk when the grid chunk is shown in the form. ... Now as you can see uh a lot of fields replaced with the grid chunks and the grid chunks here serve as field sets but bit more advanced version of field sets."

When a value, such as Maggie Simpson's balance, is modified, the changes are immediately reflected in the application interface. This live update capability is achieved as the application continuously consumes the changes stream from the external database, effectively making the resulting application live and responsive.

"Now let's amend the balance for Maggie Simpson to uh demonstrate how the change data capture works. And this uh basically makes the the uh resulting application life because it's consumes the changes string from the external database."

This ensures that the underlying database schema remains unaltered. While change data capture (CDC) setup is configured differently for various database systems like PostgreSQL and SQL Server, the actual schema itself is merely inspected.

"uh during initial generation not except that some uh change data capture setup is being uh is being done in one way for posgress uh in another way like for SQL server and so on but the shimmer itself like tables columns and index and so on are just uh being uh just being like inspected and that's it"

The primary focus of the engine, in its current evolutionary stage, is to generate applications primarily from a UI perspective. Any data changes resulting from these existing triggers or procedures are seamlessly reflected in the UI via the CDC pipeline, maintaining the integrity of the database's native logic.

"basically uh they are because uh the uh indie engine itself does not touch them because the the whole point at at least at at the current step of the of the evolution is about to generate the application uh uh primary from the UI perspective uh as as a starting point"

When an external database schema evolves after initial application generation, Indi Engine anticipates changes such as new tables, columns, or deletions upon reconnection. The system detects these modifications, prompting the developer to decide how to integrate them into the existing app design. This workflow is crucial for enterprise environments where database structures frequently change post-deployment, allowing developers to map changes by ignoring, reflecting, or renaming elements.

"when we reconnect uh the systems should somehow detect the changes like hey there is like a few new tables appeared or a few new columns or some columns were removed or renamed. Uh so basically there should be some like uh uh some workflow where the user as a developer should decide like here okay we have the app design derived from we this version of database schima and now we have the these changes on top of of that version. So what should we do?"

This constraint arises from technical differences, such as variations in data type precision, which can lead to data loss during migration. For example, a `datetime2` column in SQL Server with seven fractional seconds might lose precision when moved to PostgreSQL, which only supports six fractional seconds.

"from the technical point of view the uh database app design project are portable from one installation to another. uh but right now they are not portable from uh uh different database engines. That's basically not not a huge to-do but still still a to-do because for example if you have like daytime two column which have like by default seven seven uh seven uh precision of seven fractional seconds we on the SQL server and you would like to like uh uh set up the same database app design project on the posgress where only the six fractional seconds are possible."

Indi Engine's ability to infer business logic is limited to information directly derivable from the connected database schema. It does not inherently process or infer logic that exists outside this database layer. For modernizing legacy applications, this means that any business logic residing in legacy source code must be explicitly mapped to equivalent API calls and UI functionality within the new application.

"basically the answer is uh it does not because when you connect to external database the only info you can like process somehow or infer from that somehow is the database you have nothing else"