# |
Oct 3rd 2018, 14:50 |
ricksaccous |
i could put technically "valid" data |
# |
Oct 3rd 2018, 14:50 |
ricksaccous |
basically i could look at one field, and based on the relationships of that field (in the same table) the fk has a chance of being some value, but the relationships between the tables also means the fk could also have other values |
# |
Oct 3rd 2018, 14:48 |
btx |
how do you know it’s not accurate enough, like what is the inaccuracy? |
# |
Oct 3rd 2018, 14:47 |
ricksaccous |
i don't even know, lol |
# |
Oct 3rd 2018, 14:47 |
btx |
how would you handle the exceptions otherwise? manual linking? |
# |
Oct 3rd 2018, 14:46 |
ricksaccous |
and i can make it fairly accurate but not accurate enough |
# |
Oct 3rd 2018, 14:46 |
btx |
so , add column (without fk), link data, add fk |
# |
Oct 3rd 2018, 14:46 |
ricksaccous |
no i thought about it |
# |
Oct 3rd 2018, 14:46 |
btx |
could you add a script that links the field properly |
# |
Oct 3rd 2018, 14:46 |
ricksaccous |
yes |
# |
Oct 3rd 2018, 14:46 |
btx |
and that other table already exists with data in it? |
# |
Oct 3rd 2018, 14:46 |
ricksaccous |
the data "should" exist |
# |
Oct 3rd 2018, 14:45 |
ricksaccous |
to another table |
# |
Oct 3rd 2018, 14:45 |
ricksaccous |
no, i'm adding a column that i also want to attach a foreign key to |
# |
Oct 3rd 2018, 14:45 |
btx |
aren’t you adding a column for something that doesnt exist yet? |
# |
Oct 3rd 2018, 14:44 |
ricksaccous |
in this scenario maybe c) is the best option? |
# |
Oct 3rd 2018, 14:44 |
ricksaccous |
my choices are a ) junk data b) truncate or i guess c ) column can be nullable (even though it shouldn't) |
# |
Oct 3rd 2018, 14:43 |
ricksaccous |
before i figured i would just put junk data in it and they would realize it and fix it later or something, but it's prob better to just truncate it |
# |
Oct 3rd 2018, 14:43 |
lubos |
don't truncate if it is not what you (your next app stage) should do |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
are you sure |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
hey dude, you are truncating x table |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
and want to give a message somehow |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
lol |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
i just don't want another dev to be surprised that the table got truncated |
# |
Oct 3rd 2018, 14:42 |
btx |
im sure lots of people don’t - I just don’t have the expertise to know how to safely automate them |
# |
Oct 3rd 2018, 14:42 |
ricksaccous |
yeah, we should too at this point |
# |
Oct 3rd 2018, 14:42 |
btx |
yeah |
# |
Oct 3rd 2018, 14:41 |
btx |
migrations are some of the most destructive changes you can make |
# |
Oct 3rd 2018, 14:41 |
ricksaccous |
you run migrations manually? |
# |
Oct 3rd 2018, 14:41 |
btx |
you’re more trusting than I am I guess |
# |
Oct 3rd 2018, 14:41 |
ricksaccous |
we'll have to fix that |
# |
Oct 3rd 2018, 14:41 |
ricksaccous |
we do i think but it's kind of borked |
# |
Oct 3rd 2018, 14:40 |
btx |
do you have an automated migrations routine? (eg a deployment bot that auto-triggers migrations) |
# |
Oct 3rd 2018, 14:40 |
ricksaccous |
but i'm still worried about the prospect of half pushing it up for some reason |
# |
Oct 3rd 2018, 14:40 |
ricksaccous |
now we are not even close to being in production for this, we have no client data for this table |
# |
Oct 3rd 2018, 14:39 |
ricksaccous |
and it pretty much requires a truncate |
# |
Oct 3rd 2018, 14:39 |
ricksaccous |
because i'm adding a non-nullable fk to a table |
# |
Oct 3rd 2018, 14:39 |
btx |
lol |
# |
Oct 3rd 2018, 14:39 |
ricksaccous |
and halt if they choose no |
# |
Oct 3rd 2018, 14:39 |
ricksaccous |
just to say "are you sure you want to run this?" |
# |
Oct 3rd 2018, 14:38 |
ricksaccous |
no |