Skip to content
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

Get rid of SQLite in favour of MySQL #7

Open
dbf256 opened this issue Aug 11, 2016 · 3 comments
Open

Get rid of SQLite in favour of MySQL #7

dbf256 opened this issue Aug 11, 2016 · 3 comments

Comments

@dbf256
Copy link

dbf256 commented Aug 11, 2016

Hi,
very often when I use mmwatch there is a

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.

It is not a serious issue. No details for the error are provided, so I can't submit a better report/patch.
Thanks.

@Zverik
Copy link
Owner

Zverik commented Aug 11, 2016

I know, though thanks for reporting this as an issue.

MMWatch now uses an SQLite database for storing data. It is known for a bad concurrency. These errors happen when there is an update going on in the background, once every three minutes, so the frontend cannot read the locked database. Nothing is broken, and when you reload in 10-15 seconds, it should work.

Although I really would need to convert the datatabase to mysql.

@Zverik Zverik changed the title Frequesnt 'Internal Server Error' Get rid of SQLite in favour of MySQL Aug 11, 2016
@dbf256
Copy link
Author

dbf256 commented Sep 28, 2016

Do we have sqlite dump available somewhere? I can try to convert it to mysql sql-based dump.

@Zverik
Copy link
Owner

Zverik commented Sep 28, 2016

There is an issue with MySQL: full unicode support needs 4 bytes per character, and one of the indexed fields is 255 chars long. But MySQL cannot use indexed varchar fields longer than 768 bytes.

The production instance at maps.me uses PostgreSQL, not sure how to do this on osmz.ru yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants