-
Notifications
You must be signed in to change notification settings - Fork 62
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
Upgrade from 2.0 -> 2.1 Issues #111
Comments
Thank you for opening this ticket! In short, migration from 2.0 to 2.1 is more complex then just DB changes. Just DB part will not work even if you succeed in fixing db migrations; why? because 2.1 introduces new DB model for document version which wasn't there before :). A picture will help understanding why DB changes won't work: As you see from the picture, the "Document Version" model was introduced in 2.1 (before that, document versions were "stored" only on file-system). There is literally no information about document version(s) in DB before 2.1 version. Another important change is actually what information is stored on the file-system level i.e. what and how OCRed data is stored Long story short - at this moment you don't need to do anything. The only caveat is that your metadata information will not be transferred - as 2.1 currently does has the concept of matadata. Metadata will be re-introduced in later releases. Again, I will provide soon necessary tools and documentation on how to migrate from 2.0 to 2.1. |
Hi @ciur! Thanks again for all your work on this. I saw the newest release and wanted to follow up on this and see if there has been any progress on a migration path from 2.0->2.1? |
Hey @ciur, any news about the migration to 2.1? I'm currently using the old linuxserver image (2.0x), but would love to switch over and upgrade to a new version. Should it work? |
Hi @ciur |
It really seems like a mess :'/ Breaking update from 2 → 2.1 and another breaking update from 2.1 → 3.0… |
Yes, I agree, it is confusing and painful to have those breaking incompatibilities. When I started this project I had no idea how to write a DMS software and as result I made terrible mistakes in design of the application. The outcome was very painful maintenance of the code base. Also adding new features was hard because of the base structure on which the entire project was built. Because I have big plans for the project and because the project is still relatively new I've decided to break backward compatibility for the sake of fixing design errors in early stage of the project. The good part is that since 3.0 there won't be any breaking changes in terms of how files are stored on the disk and database schema: this means that once in 3.0 you will be able to update to 3.1, 3.2, 3.3,... without any problem.
All great features present in 2.0 (like sharing files between users, metadata, automates) will be back. Both "sharing of the files between users" and "metadata" will be back this year (2024).
In short term yes - because of large code base refactoring inevitably some of the non essential features need to be "temporary removed". But in long term, features from 2.0 will be back in significantly better shape.
I am currently in deep dive mode with 3.3; with 3.3. released, I will dedicate time for documenting migration from 2.0 and 2.1 directly into 3.x. |
Thank you very much for you effort on this great project.
That is the important information. At least I can and will wait some more time to upgrade later. Thanks. |
Thanks for the fast and informative reply and the promise of a stable future. I think that is really important for a DMS.
That sounds great, and then I will wait instead of trying to migrate everything to another software, as there is currently no real pressure except the missing updates. |
I've been trying to get my papermerge 2.0.1 installation updated to the new 2.1 release, and having lots of issues. The root of the issue seems to be that the
core_user.id
column in my old database is an integer, when some migrations are expecting auuid
field. This means that 9 migrations fail to apply when first launching, and from there everything just seems to cascade and I can't sign in due to more errors with the core_user table when attempting a login.Is this an upgrade that's expected to work? Right now things seem pretty borked, but I'm happy to pull a DB backup and help gather more data if this is something that's expected to work
The text was updated successfully, but these errors were encountered: