Closed ChriWiChris closed 7 years ago
infortunately meters do not have a contraints as teh foreignkey contraints goes only in one direction. I think it is possible to make higher level contraints but would not go this route right now.
but we should make sure our data is valid from a ruby point of view and add foreignkeys where possible, as ruby allows low-level DB actions bypassing validations.
the missing address on when there is contract is bad but not a show stopper as it states that we would like to ensure an address on the register when the register has a contract.
I did add all those log to get a feeling what the state of DB on staging.
above you see a lot of false
with the meters and registers that should not be the case but I am not sure how much we can 'fix' automatically there. investigation is needed what is wrong there. could be all the missing address in the end.
still do not see why staging is acting so broken after seeing this log
or can it be that if the meter is not valid then you can not create a broker for it ?
I don't know but it might be the case ... I really would like to investigate this with you together but I have to leave now ... Would you go deeper into this? Maybe Felix had a look at it already, please ask him if he has some information on this.
@mkristian will this ticket #683 fix this migration bug?
I think I solved this issue. The problem was a mixture of too many new constraints on our data and a bad migration script. @ffaerber Now I want to test all our migrations against real production data. Can you please show me how to make a dump of the production DB and how to import it locally? I'm still fighting against a cold so I don't know when I will be online tomorrow.
This is really important as it is one of our last steps before deploying production.
Some of the migrations don't work properly when migrating the staging environment. That's why there are some missing DB objects etc.
To reproduce this I went back to commit
655f73e06cb6a5b9cac2fe2110400d4e172521d9
which we are running on production. Then i randb:init
and went back to our current commit,b662ebdcb4922c2513c1b8ed46ec0b8bd001d601
, where i randb:migrate
. This produced the following output:The insertion of foreign keys should always ensure that current data won't get invalid. So it would be great to modify all invalid objects to be valid in the new schema.