IP Library Patent Application 18349837
Patent Application
App. No. 18/349,837

HIGH SPEED DATABASE SCHEMA CHANGE DETECTION

Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US None
App. No.
18/349,837
Abstract

Embodiments describe a technique for database schema migration that minimizes queries to the runtime database. A technique is described for detecting whether design time metadata has changed during a schema migration without performing a database query for runtime metadata and comparing the design time metadata with the runtime metadata. The technique may improve performance since it aims at minimizing the number of times the database is queried for runtime metadata during the schema migration.

Claims (56)

1 . A method comprising:

detecting a request for a schema migration in a database, the database including a database object;

reading a design time metadata associated with a current state of the database object;

generating a first file hash from the design time metadata;

retrieving a second file hash from a schema migration table, the second file hash associated with a previous state of the database object;

comparing the first file hash and the second file hash;

determining that the database object has changed during the schema migration by comparing the first file hash with the second file hash; and

upon determining that the database object has changed during the schema migration, further performing the steps:

querying the database for a runtime metadata associated with the database object;

comparing the runtime metadata and the design time metadata;

altering the database object in the database based on the comparison; and

writing the first file hash into the schema migration table.

2 . The method as in claim 1 , wherein the database object has changed when the first file hash is different than the second file hash.

3 . A method as in claim 1 , wherein the schema migration table stores at least one of following along with the second file hash: a file path of the database object, a version number of the database object, a version number of an application accessing the database; and a last update time of the second file hash.

4 . A method as in claim 1 , wherein altering the database object includes adding a column to a database table representing the database object during runtime.

5 . A method as in claim 4 wherein altering the database object includes generating a DDL statement containing instructions to add the column to the database table.

6 . A method as in claim 1 wherein the design time metadata is associated with a current state of a second database object, the method further comprising determining the second database object is unchanged during the schema migration when the first file hash equals the second file hash.

7 . A method as in claim 1 wherein the first file hash is based on SHA-256 hashing algorithm.

8 . A method as in claim 1 wherein the design time metadata is considered the ground truth when comparing the runtime metadata and the design time metadata.

9 . A system for database schema migration comprising:

one or more processors;

a non-transitory computer-readable medium storing a program executable by the one or more processors, the program comprising sets of instructions for:

detecting a request for a schema migration in a database, the database including a database object;

reading a design time metadata associated with a current state of the database object;

generating a first file hash from the design time metadata;

retrieving a second file hash from a schema migration table, the second file hash associated with a previous state of the database object;

comparing the first file hash and the second file hash;

determining that the database object has changed during the schema migration by comparing the first file has with the second file hash; and

upon determining that the database object has changed during the schema migration, further performing the steps:

querying the database for a runtime metadata associated with the database object;

comparing the runtime metadata and the design time metadata;

altering the database object in the database based on the comparison; and

writing the first file hash into the schema migration table.

10 . The system of claim 9 , wherein the database object has changed when the first file hash is different than the second file.

11 . The system of claim 9 , wherein the schema migration table stores at least one of following along with the second file hash: a file path of the database object, a version number of the database object, a version number of an application accessing the database; and a last update time of the second file hash.

12 . The system of claim 9 , wherein altering the database object includes adding a column to a database table representing the database object during runtime.

13 . The system of claim 12 , wherein altering the database object includes generating a DDL statement containing instructions to add the column to the database table.

14 . The system of claim 9 , wherein the design time metadata is associated with a current state of a second database object, the method further comprising determining the second database object is unchanged during the schema migration when the first file hash equals the second file hash.

15 . A method as in claim 9 wherein the design time metadata is considered the ground truth when comparing the runtime metadata and the design time metadata.

16 . A non-transitory computer-readable medium storing a program executable by one or more processors, the program comprising sets of instructions for:

detecting a request for a schema migration in a database, the database including a database object;

reading a design time metadata associated with a current state of the database object;

generating a first file hash from the design time metadata;

retrieving a second file hash from a schema migration table, the second file hash associated with a previous state of the database object;

comparing the first file hash and the second file hash; and

determining whether the database object has changed during the schema migration by comparing the first file hash with the second file hash; and

upon determining that the database object has changed during the schema migration, further performing the steps:

querying the database for a runtime metadata associated with the database object;

comparing the runtime metadata and the design time metadata;

altering the database object in the database based on the comparison; and

writing the first file hash into the schema migration table.

17 . The non-transitory computer-readable medium of claim 16 , wherein the database object has changed when the first file hash is different than the second file hash.

18 . The non-transitory computer-readable medium of claim 16 , wherein the schema migration table stores at least one of following along with the second file hash: a file path of the database object, a version number of the database object, a version number of an application accessing the database; and a last update time of the second file hash.

19 . (canceled)

20 . The non-transitory computer-readable medium of claim 16 , wherein the design time metadata is considered the ground truth when comparing the runtime metadata and the design time metadata.

21 . The non-transitory computer-readable medium of claim 16 , wherein altering the database object includes adding a column to a database table representing the database object during runtime.

Assignments (2)
CHANGE OF NAME Recorded Jan 26, 2026
From: BUSINESS OBJECTS SOFTWARE LIMITED
To: SAP IRELAND LIMITED
Reel/Frame 074510/0354 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 10, 2023
From: SHEEDY, PAUL; O'CONNOR, PAUL
To: BUSINESS OBJECTS SOFTWARE LTD
Reel/Frame 064204/0090 →