Feat/orm search

[kfsone]

wip - I still need to round out the tests, but if either of you wants visibility before then.

• I put it in db because that's how I think, what I was avoiding was blowing trade.py away with this specific sub-concern;
• my first next alternative was having "tradeorm" be a directory rather than a single file, so it could be broken up accordingly, but in that case it felt like it should just be called "db" back to square one :)
• why did I think "well this isn't tradeorm"? Just hits me as not actually an ORM specific concern per-se.

[Tromador]

If you think it's better in db, I am fine with that. Especially if there's likely to be any db specific code for either backend.

My original thinking was to keep the db mess out of the pure TD codebase, so that any incoming dev could work on algorithms and other improvements to the way we work without needing to involve the DB, or should the database get in the way, it's all in one place and one doesn't have to go a-grepping to find all the touchpoints. This was something I had to do at length when I did the refactor, and knowing how long it took just to find all the places where there was raw SQL and such, I'd like for future me (or you, or whomsoever) to be able to avoid that pain next time.

So don't worry about using that folder if you think it appropriate, I don't own it.

[kfsone]

If you think it's better in db, I am fine with that. Especially if there's likely to be any db specific code for either backend.

My original thinking was to keep the db mess out of the pure TD codebase, so that any incoming dev could work on algorithms and other improvements to the way we work without needing to involve the DB, or should the database get in the way, it's all in one place and one doesn't have to go a-grepping to find all the touchpoints. This was something I had to do at length when I did the refactor, and knowing how long it took just to find all the places where there was raw SQL and such, I'd like for future me (or you, or whomsoever) to be able to avoid that pain next time.

nod I'm calling it out to check with someone more knowledgeable/appropriate whether I picked the right cut-point for separation of concerns. db/search.py as it is mostly just builds queries using the orm; but I can totally see how that might be the wrong line.

Otoh - I wasn't sure if it might not end up being the portion of the feature that ends up with dialect specific quirks etc - I dunno - some magic wompawompaindex for ZoolookDB or something.

[kfsone]

Ok - I'm going to integrate the game journal stuff, too, so that ~ and ~@ work anywhere you use a system or station name. But I'm going to think about it a bit first because I want to avoid creating a dependency mess.

[eyeonus]

sounds good i like both the functionality and the caution

…

On Sat, Feb 7, 2026 at 1:14 PM Oliver Smith ***@***.***> wrote: *kfsone* left a comment (eyeonus/Trade-Dangerous#280) <#280 (comment)> Ok - I'm going to integrate the game journal stuff, too, so that ~ and ~@ work anywhere you use a system or station name. But I'm going to think about it a bit first because I want to avoid creating a dependency mess. — Reply to this email directly, view it on GitHub <#280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANHHYADLLCGUIYZ2QO52AD4KZBT3AVCNFSM6AAAAACSXFLC62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRVGIZDOOBSGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- mu'o mi'e .aionys. .i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o (Come to the Dot Side! Luke, I am your father. ^_^ )