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

Cache rating edit #1381

Open
deg-pl opened this issue Jan 28, 2018 · 7 comments

Comments

@deg-pl
Copy link
Member

commented Jan 28, 2018

From Amberel (OC UK team):

It would be nice to be able to edit a cache rating. I realised after posting a log yesterday that I had clicked the wrong rating, but I can see no way to go back and change it to the correct one.

@rapotek

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

By the way: why the table which stores information about recommendations only is called 'cache_rating' and the table used to store real ratings is called 'scores'?

@kojoty

This comment has been minimized.

Copy link
Member

commented Jan 28, 2018

@rapotek, I'm afraid there is no answer for such question and there are much more questions like that.

@andrixnet

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

renaming the tables will make it tricky to update the nodes, right?

@kojoty

This comment has been minimized.

Copy link
Member

commented Jan 30, 2018

I think that table renaming is possible but difficult in our current process because we need to do two things:

  • apply changes in the code - what is done automatically at merge to master branch in repo
  • apply db changes - what is done manually before or after merge (depends on request)

In my opinion it would be useful to develop solution for automatic DB updates - then such operations would be much more easy to do - another side of such solution is a danger - possibility of breaking something at remote node without access to it

Maybe we can go in opposite direction and prepare some kind of "flap", which stops automatic merges from repo at node level if change needs paralel db update - then node admin apply the sqlalter and update code manually in one time and turn on automatic updates again - such process could be used only for "specific" updates - I'm not sure how to implement it now - but it could be more safety solution.

Maybe you have better idea for this issue?

@andrixnet

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2018

It is also tricky because of a wider range of database servers used across nodes and support for some delicate details. This would also require extensive error checking to roll back changes to both DB and code, should any DB change fail.

Your second suggestion, given also our close knit community, makes more sense.
I'll open a new issue on the matter.

@andrixnet andrixnet referenced this issue Feb 2, 2018
0 of 7 tasks complete
@following5

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2019

@rapotek

why the table which stores information about recommendations only is called 'cache_rating'

Because that table is inherited from OCDE, which does not have ratings, and the German developer who implemented recommendations confused the English terms. ;)

@kojoty

I think that table renaming is possible but difficult in our current process
...
In my opinion it would be useful to develop solution for automatic DB updates - then such operations would be much more easy to do

Automatic DB updates now are implemented, but they cannot do automatic rollback. This means: If a table or column is renamed, then may not possible to check out and run code versions prior to this change, which somtimes is useful for finding the commit that introduced a bug.

@kojoty

This comment has been minimized.

Copy link
Member

commented Jan 27, 2019

Automatic DB updates now are implemented, but they cannot do automatic rollback. This means: If a table or column is renamed, then may not possible to check out and run code versions prior to this change, which somtimes is useful for finding the commit that introduced a bug.

I agree, but I afraid that every significant change of DB make running "old" code impossible...

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