please let us know the result of Repo.all
I’d go even further. Once you insert a record in iEX
, use the MySQL shell to show you what value in the id
column actually is. Something like:
SELECT HEX(id), nth, url, contents FROM sources;
That really is the only way to know what was actually written to the database as the UUID data can just as easily be compromised on the Repo.all
return trip.
The table is empty before that and id column is a primary index (must be unique), so in either case, there couldn’t be duplicate ids in the table.
The fundamental issue here is that you have shown that in your environment the result of the query cannot necessarily be trusted. Given that there is only one record in the table, multiple distinct IDs seem to be returning the same record which can only have one ID. So there could be a whole set of ID values capable of selecting this one record.
You write the record with ID A and you retrieve with ID A something with ID B.
- If the query works then ID A is in the database and ID B is a version of ID A that is somehow corrupted on the way back from the database.
- If the query works - ID A could be corrupted before being written as ID B to the database. ID A could be corrupted in a similar fashion during the query becoming ID B and then retrieving the data of the ID B record.
- If the query doesn’t work it simply returns the only row in the table. While ID B is different from ID A it’s not clear whether ID A was corrupted before writing it to the database or after reading it from the database.
So at this point superficially it looks like ID B is in the database but it could be corrupted on read, so ID A could still exist in the database.
Now you retrieve with ID B and get something with ID B.
- If you believe the query works and take the previous observations into account then you have to believe the whatever corrupted ID A into ID B doesn’t change the value of ID B - allowing the query to actually seem to work the way it should if ID B is actually in the database.
- If you are open to the possibility that the query simply returned the only record in the table then you can’t have any confidence in the ID value being retrieved as it is clearly being corrupted somewhere - before writing, after reading, both?
Given that it seems that the ID value is being corrupted somewhere, there is the possibility that sometimes ID related queries will not work (depending on the nature of the corruption).
To narrow this down you should create a minimal ecto-only project with a single table in a new database with an UUID column and a second (string) column for information that lets you uniquely identify each record created for inspection.
Set up a unit test similar to the one you have. You may have to run the test repeatedly until it fails (or some max is reached) - sometimes these type of defects are intermittent.
Once you have a setup that consistently fails in your environment, put the project up on GitHub and reference the repository in the issue. That way somebody else can easily try it in their (MySQL) environment to see if the problem behaviour persists.