But… you can just comment out the defimpl Inspect temporarily? Nobody is saying “nuke it from orbit”. 
We’re talking about you making a temporary local change so you can test. Nobody is saying to change the code on the production servers.
Really curious about that PR, can you send link when it’s up?
1 Like
thank. u @dimitarvp did just that last night, will continue today on it full time. will let u know what happens.
now there are three of us working on it now in my group and it’s got all of us STUMPED, so I don’t feel to bad now… LoL
I’ll tell you this forum is REALLY very useful… thank you all
@lc0815 check your Private messages.
@dimitarvp I will link from here to the PR which I will probably submit later on today.
1 Like
@dimitarvp update: removed the defimpl and did not get any errors, but the data content did change drastically but no end in sight… still researching. I’ve been out on training for past few days… on it today again…
This is what we’ve been trying to tell you. The data did not change when you removed the defimpl. It merely displayed the data as it is, rather than according to the special display rules in the defimpl. The defimpl only controls how the data is printed to the console, not the contents of the struct. You can pattern match on the struct to pull out the internal values and use them in your code.
2 Likes
Yeah that was expected. Removing a helper to format a struct does nothing. The original data is still there, you just see it a different way.
You panic too much!
Now what was the original problem again?
1 Like
that is true, but what is even truer is that the problem is still a problem with no solution at hand and when you have several folks looking at your performance, then it is not longer a panic moment, its a catastrophic event 
Eh, it happens to all of us, try and calm down and you’ll perform better. Take two shots of whiskey if necessary!
So okay, what string were you trying to split and why?
1 Like
just to clarify, by looking at other parts of the code, the implementation is correct. the value field is expected to be an atom, not an integer.
Fix that, because temporaily removing the implementation will not solve anything, your code downwards will not work if if value is an integer.
2 Likes
Yep, same as what I observed. It’s just that IMO if OP reruns their code and finds the actual problem and addresses it – by also showing us the process here in the forum – they are a bit more likely to get peace of mind.
When one is super stressed, starting to wonder if you are seeing things is sadly common place.
But yep, let’s see what they say when they are back.
1 Like
While I can agree that these are both generally true. They are not absolutely true. I would not recommend removing a defimpl Inspect from a codebase that you don’t understand since some code could be calling inspect(struct) and then using or further modifying that result. So removing the defimpl Inspect could break the codebase (although generally it should not, especially in a well-designed system).
But I do definitely agree with removing it temporarily so that the developer can better understand the specific data structure they’re working with.
That’s very impressive work, good job!
1 Like
I mean yes, we all recommended temporary removal just so OP can be unblocked on their main issue (if there was any 
).
But I have the creeping feeling that such a custom Inspect implementation also means that other code in that codebase relies on this custom string format. I think the original problem that OP showed demonstrates this somewhat. Hopefully they come back and tell us more.
1 Like
Sure it could break the codebase, but I’d argue if you’re relying on the inspect protocol implementation for anything other than logging that’s probably a code smell. I’m sure someone will come out of the woodwork with a valid use case, but I don’t think that’s relevant to the topic at hand.
The point I was trying to make, is regardless of whether or not you have a struct protocol implemented for a struct makes no difference when handling values that are that struct type. They still pattern match the same, they still have the same fields, same values, the only thing that changes is how it is printed when printing that value in iex or elsewhere.
1 Like
There is also a third option that @eksperimental mentioned, which is using the Atom representation with a colon like value: :"25" - have you tried this?
1 Like
to all who responded to this very interesting problem, I would like to offer my most grateful thank you’s, I have learned a lot and have taken your suggestions to heart. in some cases I have played with the code in IEx and have found similar results dealing with the struct in question.
I do agree with @axelson with his correct statement of not making nili wili changes to the Inspect code as it exist because a lot of code would be broken and the solution I’m finding is working with what I’ve got and work with the struct contents and produce the values expected by the existing code, and I’m almost there.
A special thanks to @eksperimental for his efforts and his PR submission on the issues found while working with the Inspect protocol issue.
will provide with an update on the final resolution. PS: a lot code was broken with this change… and the fix will set the code back to normal, I hope.
thanks one and all, this forum is AWESOME for neophytes like me.
2 Likes
Update:
12/17/21 after doing an intense amount of reading and research, I finally found the answer by this line of code:
|> Enum.find(%{}, &(Atom.to_string(roles.cast!(&1.role).value) == default_role))
from this:
|> Enum.find(%{}, &(&1.role == default_role))
funny how the solution was such a trivial piece of code… still took me about 2 months to figure it out and did not have to change anybody else’s code either… awesome…
did learn a lot about protocols, algebra documents and pattern matching, oh and also learned that I ain’t so dumb after all, yuk yuk yuk LoL
2 Likes
