| # |
Oct 3rd 2018, 14:50 |
 btx |
and it would be up to the user to pick one? or should it be programmatically determinable? |
| # |
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?" |