Ok this is… more than weird
It’s also consistent during insert_all with conflicts. I’m trying to back fill some missing data from backup, but can’t because the db thinks they are already there…
I can’t have 20+ uuids with conflicts, right? That’d be too luck. I checked they are totally different from what’s coming back from the db. Repo.all(from x in X, where: x.id in ^my_ids) I get these 20+ results with totally different ids, but consistent!
Can you show us what does v() do?
It’s an iex helper that returns the last line, essentially. I actually didn’t know about this one because I never use iex 
Yup. The screenshot is a remote iex. v() simply refers to the previous return value.
Sorry if it’s confusing. The tldr for this is: If I `Repo.get X, “abc”` I would expect an entry of X with id abc to be returned. Here it’s giving me something different.
Same thing during insert_all, it thinks something with a different id conflicts with the entry am trying to insert.
You can also do v(-2) to get the second last result.
And v(line_number) to get a specific line.
That is certainly odd! I think you need to do some more debugging here, though. There’s not really anything for us to go off of.
Is id the primary key? What is the id in the actual database? What is the DB schema? Could there be something weird going on with autogenerate? The changeset? Etc.
Yes 
haha
On slack you said this was a remote console, are you seeing the same behavior locally? Have you checked the generated query, or tried via psql (or other db client)?
Yes id is pk
I also suspected something with ecto or auto generate, hence the test at the top, about uuid dumping and loading. All seems good. It almost seems a pg problem but that would be too crazy to be true.
From experience (and I’m sure any programmer will corroborate): bugs like this are virtually always something really stupid that you overlooked. We have all been there. But whatever it is, you’re the only one with the access to narrow it down.
Trying to reproduce in psql is a good way to rule some stuff out.
Good points. I loaded the backup into a Dev db and there wasn’t any conflict. I should dig more. And I should try psql yes.
Yup that’s why I’m kinda desperate hoping someone already had seen something similar and know the answer.
I couldn’t believe my eyes what I was seeing.
Can you please show the schema definition for the module you’re querying? It might be that it uses some special encoding of the IDs or it might use some other field as the primary key
I have had some funky behaviour like this after a pg upgrade. I fixed it by running a vacuum.
@princemaple any luck figuring this one out?
© Copyright Elixir Forum | Terms | Privacy & Cookies
