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

Fix issues with large databases #655

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@McLive
Copy link

commented Jan 3, 2016

No description provided.

@md-5

This comment has been minimized.

Copy link
Member

commented Jan 3, 2016

You also need a migration for the bigint change

RoboMWM referenced this pull request in bob7l/HawkReloaded Mar 7, 2016

@bob7l

This comment has been minimized.

Copy link

commented Mar 8, 2016

I wouldn't recommend using such a large integer. You're just wasting space by adding support for an EXTREMELY rare case. Also, as md-5 has already mentioned, this would require users to either reset or migrate their entire database just for this very very rare case (Possible impossible even?).

Not to mention the current integer type is an INT unsigned, meaning you'd have to exceed 4,294,967,295 - which at that point your database would most likely be too bloated to function properly.

@Brokkonaut

This comment has been minimized.

Copy link
Member

commented Aug 1, 2018

If you update and complete it (bigint in all tables that need it + table access getLong/setLong, automatic database upgrade), I could accept it

@McLive

This comment has been minimized.

Copy link
Author

commented Aug 12, 2018

I don't think there should be an automated migration of the database inside the plugin. That'd take hours and hurt the performance of the spigot plugin.

Doing that directly with an mysql query is the better way.

@Brokkonaut

This comment has been minimized.

Copy link
Member

commented Aug 13, 2018

A config option could be used for that. if set to enabled the upgrader would modify the database if it does not yet use bigints (or create it with bigints if it does not exist). If not set it would generate the database using ints and not modify an existing database. I don't see why upgrading the database outside of the plugin would be any faster. you can use the same sql statements in the plugin

But the main concern is that your pr only changes one table and not all of the accesses to the database to use long/bigint instead of int

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.