-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Schema in PostgreSQL DB #9312
Comments
Thank you very much! It would be great if you could create a PR |
The code should also be able to migrate old data |
At the moment the automatic migration could be dangerous: in database there is not enough information to determine if ENTRY, FIELD and METADATA tables belong to an old installation or to another application. Maybe it's worth migrating manually? |
This comment was marked as outdated.
This comment was marked as outdated.
Who chooses to use a database is a team, or a single user who needs to access the same library from different locations, but in fact can be considered a team with non-simultaneous access. In this specific transition phase from 5.7 to the future release, it became clear that the TEAM will have to plan and agree on two interventions:
Data MigrationAt the moment, manual migration is already possible with the tools available. Export from JabRef v5.7
Upgrade JabRef Stop using previous versions and encourage the switch to the new version. IDEA: Using a key-value pair in the METADATA table indicating the library version. ( The problem should also be reported during the installation of the new release with a request to backup the library. Import into new JabRef release from BibTeX
Advance MethodsFinally, there are certainly advanced methods, but it can be dangerous to implement them at this stage. I think that only after key-value pair ( |
I'm ready
Structure changes
In any case, fields of the tables have remained unchanged.
checkBaseIntegrity (VersionDBStructure)To check the integrity of the DB and to implement the automatic migration, it was necessary to add the variable
Automatic migrationBy comparing the IMPORTANT: To avoid data loss, old tables will not be deleted during migration. Old tables will need to be deleted manually. |
Automatic migrationflowchart TB
STATUS[Status: VersionDBRequired = 1] --> Check1
Check1{{ENTRY, FIELD, METADATA\ntables exist?}}
NewInstallation[VersionDBStructure==null\nThis is a new installation]
NoMigration([No Migration])
MigrationMysqlStep1([Create JABREF_ENTRY\nCreate JABREF_FILED\nCreate JABREF_METADATA])
MigrationPgsqlStep1([Create jabref.ENTRY\nCreate jabref.FILED\nCreate jabref.METADATA])
MigrationStep2([`Insert into newTable Select * from oldTable`])
Check2{{VersionDBStructure exists in DB?}}
CheckError{{Return Error?}}
NoCompatibility([There isn't compatibility between old and new structure])
Compatibility([OK, Well done!])
PrevVer([VersionDBStructure=0])
GetVersionValue([Get VersionDBStructure Value])
Check3{{VersionDBStructure < VersionDBRequired}}
Check4{{VersionDBStructure > VersionDBRequired}}
Check1 -->|NO| NewInstallation --> NoMigration
Check1 -->|YES| Check2
Check2 -->|NO| PrevVer
PrevVer -->|Try Migration MySQL| MigrationMysqlStep1
PrevVer -->|Try Migration PgSQL| MigrationPgsqlStep1
MigrationMysqlStep1 --> MigrationStep2
MigrationPgsqlStep1 --> MigrationStep2
MigrationStep2 --> CheckError
CheckError -->|YES| NoCompatibility
CheckError -->|NO| Compatibility
Check2 -->|YES| GetVersionValue
GetVersionValue --> Check3 -->|Perform Migration| Migration([Future Migrations])
GetVersionValue --> Check4 -->UpdateClient([Upgrade Client JabRef])
|
Is your suggestion for improvement related to a problem? Please describe.
I have only one postgreSQL database with a lot of tables in public schema.
In my opinion, JabRef's table names are very generic and it's easy to find another application that uses names like METADATA, ENTRY or FIELD.
Describe the solution you want
The easiest way to solve the problem is to add a suffix to the names, for example:
jabref_ENTRY, jabref_FIELD, jabref_METADATA.
In postgreSQL it is possible to create tables in a different schema, for example: jabref
In my case I prefer this
Additional context
In my local 5.7 release I made what I described with a few changes to the code.
If you think it will be useful, I can share the patch.
Greetings!
The text was updated successfully, but these errors were encountered: