mike bayer  

claude is able to do the very deep quasi-guesswork I've done for decades at this point involving the path structures SQLAlchemy uses to match various kinds of loader option structures into object select/load graphs - this is how joinedload(X.y).joinedload(Y.z) ends up in the SQL and ends up in the returned objects. It has been two decades of brain crushing work each time new issues are reported to get my head around these structures and identify new fixes. claude is not coming up with fixes the way I want them the first few times around, but it understands the system and can come up with solutions, making it the second "being" in the universe that can actually help me with these.

if I indeed don't need to flex these particular cognitions as strongly as I used to, they'll decline for sure but I hope to replace them with other ones that are more life fulfilling at this point.

Mar 23 at 5:53pmWeb
Show threadmike bayer  22h ago

originally, when it first identified how the path generated by the option wasn't matching, it first did a hack of "just make the path we want and look for it" over here: https://github.com/sqlalchemy/sqlalchemy/blob/main/lib/sqlalchemy/orm/interfaces.py#L1147

then it pretended like "I'm done! it works!" and I was like no, let's do it from the other side; make sure the path we search here is present. You can add an additional path to the output there so that there's more than one way to match (since I wasn't sure how different this path was going to be).

so then it moved the reverse of that logic, still a hack, over here where the paths get put into the dictionary: https://github.com/sqlalchemy/sqlalchemy/blob/main/lib/sqlalchemy/orm/strategy_options.py#L2084 then we were closer but I sort of knew this was logic we are already doing elsewhere earlier in the chain, so I suggested looking for that.

so then it found where that happens in path_registry and this is the fix: https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/6630/1/lib/sqlalchemy/orm/path_registry.py which is obviously the correct fix, as there is already a place this path correction is happening, it just needed to also look for the opposite pattern. that is I've already fixed a variation of this bug. so it's not even a one liner, it's just taking an existing conditional and adding another variant of the condition to it.

sqlalchemy/lib/sqlalchemy/orm/interfaces.py at main · sqlalchemy/sqlalchemy

The Database Toolkit for Python. Contribute to sqlalchemy/sqlalchemy development by creating an account on GitHub.

GitHub
Show threadmike bayer  22h ago

now, post mortem. If I was fixing this without claude, would I have done the first two ways first? probably not, I'd have pdb's over there to trace what happened, but I'd likely have remembered sooner that this is another path_registry rule.

But what did claude do for me. **it did all the analysis to find exactly where things went wrong**, it did all the grunty adding of print statements, making little self contained tests, isolating exactly the path pattern occurring. Which is GREAT, because I am very, very tired of cracking open these path schemes and holding it all in my head, while at the same time dealing with the general anxiety and stress that this case is going to be one that the architecture does not accommodate. Claude just took all that on. The overall task was definitely shorter than if I did it myself as claude was able to spit out the test cases as well, but that doesnt even matter, because the *psychic stress* of doing these bugs myself is entirely something I can do without. I am *less stressed and exhausted* because I had another "being" looking at the code and actually able to linguistically model how it works.

Show threadOwen Nelson22h ago
@zzzeek a coworker recently turned me on to the "superpowers" plugin, which is particularly well suited for just that sort of grunt work. You brainstorm approaches with the chat bot, then turn it away to toil for a while.