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

DB does not force uniqueness of location #38

Open
IAPark opened this issue Feb 11, 2016 · 3 comments
Open

DB does not force uniqueness of location #38

IAPark opened this issue Feb 11, 2016 · 3 comments

Comments

@IAPark
Copy link

IAPark commented Feb 11, 2016

Something else that may be worth considering especially as we're creating a new DB is setting
loc_x, loc_y, loc_z, loc_world here to be unique. This would prevent any possible errors resulting in Bastions getting doubled up, might even be worth making it the primary key, but I feel like that's a larger change than we really want to do.

@ProgrammerDan
Copy link

So, Civcraft isn't the only server running this plugin, and some might wind up trying to update against live data.

Any changes we make need to at least offer a smooth migration path.

That said, adding a unique constraint post-fact is possible, although tends to be messy for live data. I'll mark this for future consideration :).

@IAPark
Copy link
Author

IAPark commented Feb 11, 2016

I think it would only create the table if it doesn't already exist so not that big of a deal for other people updating.

@ProgrammerDan
Copy link

Good point. My thinking was more that we'd add it as a migration, not to the initial DB craft. If code depends on the uniqueness but we don't enforce it for migrations we create new liabilities for operators.

Maxopoly pushed a commit to Maxopoly/Bastion that referenced this issue Dec 27, 2017
Some fixes and 'allowed groups for bastion group' feature
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants