I haven’t worked with HugSQL myself, but one way of exposing functions and data is to put it in a sub namespace in the interface, e.g. my.top.ns.mycomponentinterface.interface.sql.

the issue I am asking is more about how to export the fn's? hugsql generates vars at runtime by loading and SQL file and creating a fn for every query: Doing the bellow calls will add fn's to the current namespaces.

(hugsql/def-db-fns "dre/app/db/articles/core.sql")
(hugsql/def-sqlvec-fns "dre/app/db/articles/core.sql")
(hugsql/def-sqlvec-fns "dre/app/db/articles/articles_for.sql")

But once these statements have been executed, HugSQL can then do its magic?

not sure I understand. let me give more info, maybe we can find a solution. so for example, articles/core.sql contains:

-- :name do-truncate-articles! :!
truncate articles;

(hugsql/def-db-fns "dre/app/db/articles/core.sql")

Calva complains about the fn because it does not exist in file, only at runtime

issue is that I might have lots of fn's in files and I will need to export them all

But would’t you have to do that even without Polylith?

I guess so

but since they are generated I have to do extra work with polylith (seems so, anyway)

Why do you think you have to do more work with Polylith? What is the difference?

it feels like that 🙂

becase I have to put them in interface to use them

Because you need to access them from other components?

yes

But then using a sub interface can be a good idea, having them in one place.

hmm, maybe I can have those calls directly in interface

so the interface will be the implementation

Yes, and that is allowed. It can be the best choice in some situations if you have one-liners or tiny functions.

Delegating to an implementing namespace is just best practice, in most cases.

thanks for the dicsussion. It really helped clear tings up. I did not find any info about this topic so hopefully now there is some

Okay, cool. If you have more questions later, don’t hesitate to ask.

thanks. I appreciate the help

I'm doing a push to mgrate more of our code to polylith components

Sonds like a good idea! 🙂

ah see, I ended up borrowing code from kit-clj and adding a query-fn key to my system, which resolves the queries (via a map), which are generated when the system is initialized… I should check whether the interface way makes more sense

I’ve finally found some time to go back and revisit this. The approach with the interface etc feels a lot more natural with polylith and helped simplified my codebase.