Migrate from 2.0 to 3.4 #589
Replies: 15 comments 7 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ciur |
Beta Was this translation helpful? Give feedback.
-
|
It really seems like a mess :'/ Breaking update from 2 → 2.1 and another breaking update from 2.1 → 3.0… |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@ciur any news about upgrade/migrate an installation to a new version? |
Beta Was this translation helpful? Give feedback.
-
|
@ciur So, is the unpinning a message? |
Beta Was this translation helpful? Give feedback.
-
|
Migrate to the newest version which is 3.3. |
Beta Was this translation helpful? Give feedback.
-
|
@duracell Are you on 2.0? Is the migration problem still relevant ? The plan now is to provide migration scripts from 2.0 to 3.4. So I will update this ticket title as "migrate from 2.0 to 3.4". |
Beta Was this translation helpful? Give feedback.
-
|
Hey, my Papermerge is on version 2.0, but unfortunately, it’s no longer relevant for me. After the comment I spent several hours migrating to a different solution and completely rebuild my scanning workflow. I see the complexity and lower priority of the whole migration topic, so I didn’t want to wait hoping or annoy you with asking again. |
Beta Was this translation helpful? Give feedback.
-
|
Is there anybody interested in migrating from 2.0 to 3.4 ? If yes, now is the moment to raise your hand. |
Beta Was this translation helpful? Give feedback.
-
|
Good to know. I will provide migration instructions (+ required apps) by the end of these month (February 2025). |
Beta Was this translation helpful? Give feedback.
-
|
@ReneHezser What database do you use ? Which version ? |
Beta Was this translation helpful? Give feedback.
-
|
@ciur Thanks for your work. I am using the linuxserver image linuxserver/papermerge:v2.0.1-ls60 The package libmariadb3 is installed in that image. |
Beta Was this translation helpful? Give feedback.
-
|
@ReneHezser could you pls provide me with your configuration? i.e. docker compose file + papermerge.conf.py file so that i can sort of reproduce your setup locally? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ciur My compose file (parts of it). papermerge.conf.py #DBTYPE = "mariadb" # Uncomment this to enable an external DB instead of local SQLite, refer to Papermerge docs
DBUSER = "root"
DBPASS = "root"
DBHOST = "mariadb"
DBNAME = "papermerge"
MEDIA_DIR = "/data/media"
STATIC_DIR = "/app/papermerge/static"
MEDIA_URL = "/media/"
STATIC_URL = "/static/"
OCR_DEFAULT_LANGUAGE = "deu"
OCR_LANGUAGES = {
"deu": "Deutsch",
"eng": "English",
}
LANGUAGE_CODE = "de-DE"
BINARY_STAPLER = "/usr/local/bin/stapler"settings.py from .base import * # noqa
DEBUG = False
# debug variable in templates is available only if INTERNAL_IPS are set
# to a not empty list
INTERNAL_IPS = [
'127.0.0.1',
]
ALLOWED_HOSTS = ['*']
INSTALLED_APPS.extend(
['mod_wsgi.server', ]
)
# DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.postgresql',
# 'NAME': 'dbname',
# 'USER': 'dbuser',
# 'PASSWORD': 'dbpass',
# 'HOST': 'db',
# 'PORT': 5432,
# },
# }
# DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.mysql',
# 'NAME': 'dbname',
# 'USER': 'dbuser',
# 'PASSWORD': 'dbpass',
# 'HOST': 'db',
# 'PORT': 3306,
# },
# }
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": "/data/papermerge.db",
}
}
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'file_worker': {
'class': 'logging.FileHandler',
'filename': 'worker.log',
},
'file_app': {
'class': 'logging.FileHandler',
'filename': 'app.log',
},
},
'loggers': {
'mglib': {
'handlers': ['file_app'],
'level': 'DEBUG'
},
'papermerge': {
'handlers': ['file_app'],
'level': 'DEBUG'
},
'celery': {
'handlers': ['file_worker'],
'level': 'INFO'
},
},
}
CELERY_BROKER_URL = "redis://localhost"
CELERY_BROKER_TRANSPORT_OPTIONS = {}
CELERY_RESULT_BACKEND = "redis://localhost"Thanks a lot. |
Beta Was this translation helpful? Give feedback.
-
|
I was able to start the app. I am using mariadb 11.2. Here is the compose file with which I started your setup: |
Beta Was this translation helpful? Give feedback.
-
I am not running maria db outside of that container. The comment
Yes, I am running on
I don't think you need maria db, as at least I am not using it. Thanks for your effort! |
Beta Was this translation helpful? Give feedback.
-
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.idcolumn in my old database is an integer, when some migrations are expecting auuidfield. 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
Beta Was this translation helpful? Give feedback.
All reactions