		@@ -251,3 +251,3 @@ # Linked QL

		with each of those also needing to be paired with the "DOWN", reverse-engineering logic:
		with each of those also needing to be paired with a "DOWN" logic (the reverse-engineering logic):

		@@ -294,3 +294,3 @@ ```sql

		And you're able to access the same savepoint on-demand using the [`database.savepoint()`](https://github.com/linked-db/linked-ql/wiki/API#databasesavepoint) API:
		You're able to access the same savepoint on-demand using the [`database.savepoint()`](https://github.com/linked-db/linked-ql/wiki/API#databasesavepoint) API:

		@@ -318,3 +318,3 @@ ```js

		✨ That's your go-ahead to alter your DB carefree! You've got a safety net!
		✨ Now, that's your go-ahead to alter your DB carefree! You've got a safety net!

		@@ -331,5 +331,5 @@ Taking that further, you also get a way to roll forward from a rollback state! (Much like hitting "Redo" to reverse a certain "Undo").

		✨ You essentially get time travel in any direction - and as seamlessly as you move on a movie track!
		You essentially get time travel in any direction - and as seamlessly as you move on a movie track!

		Meanwhile, your schema histories are now being encoded as data (instead of as files), making them queryable, analyzable, and even visualizable, as regular data!
		_✨ Meanwhile, your schema histories are now being encoded as data (instead of as files), making them queryable, analyzable, and even visualizable, as regular data! Plus, the DB now essentially becomes the absolute source of truth for both itself and its client applications!_

		@@ -340,3 +340,3 @@ ## Re-Introducing Schema-as-Code with `schema.json`

		With schema versioning now over to the database, much of the old conventions and formalities should now be irrelevant. We found that you could essentially streamline you whole "database" footprint from spanning dozens of migration files to fitting into a single `schema.json` (or `schema.yml`) file!
		With schema versioning now over to the database, and given the freedom to not need to keep certain schema histories to manually maintain past states (or risk losing them), we found that you could essentially streamline you whole "database" footprint from spanning multiple files to fitting into a single `schema.json` (or `schema.yml`) file!

		@@ -624,3 +624,3 @@ ### `schema.json`

		Now, if you had that somewhere in your application, say at `./database/schema.json`, Linked QL could help keep it in sync both ways with your database:
		If you had that somewhere in your application, say at `./database/schema.json`, Linked QL could help keep it in sync both ways with your database:

		@@ -632,4 +632,2 @@ + you add or remove a database object or table object or column object... and it is automatically reflected in your DB structure at the click of a command: `linkedql migrate`

		Thanks to a DB-native schema version control system, no need to maintain past states, or risk losing them; the DB now becomes the absolute source of truth for both itself and its client applications, as against the other way around. (You may want to see how that brings us to [true "Schema as Code" in practice](#test-heading).)

		To setup:
		@@ -676,6 +674,8 @@

		(More details in the [Linked QL CLI](https://github.com/linked-db/linked-ql/wiki/CLI#linked-ql-cli) section.)
		(Details of these commands in the [Linked QL CLI](https://github.com/linked-db/linked-ql/wiki/CLI#linked-ql-cli) section.)

		🐣 And that's a wrap!
		_✨ That's the goodbye to dozens of migration files and its processes! (You may want to see how that brings us to [true "Schema as Code" in practice](#test-heading).)_

		🐣 And that's a wrap on Linked QL!

		## DOCS
		@@ -682,0 +682,0 @@

@linked-db/linked-ql - npm Package Compare versions

Improved metrics