how are folks structuring code for objects that ex...

# exposed

[aryeh]

how are folks structuring code for objects that extend Table() ?

In particular, say I want to do SomeTable.insert { ... } -- then I need to import import org.jetbrains.exposed.sql.* to get the insert extension

This means, say, if I want to do this operation some place other than the SomeTable impl itself, I have that broad import statement

This is different coming from popular ORMs in ruby, django -- not a bad thing per se

Three ways to structure I can think of:
• write wrapper instance methods for the the SomeTable that call insert under the hood
• do the broad import
• something else?
I'm tentatively inclined to do the latter -- thoughts?

[Andromadus Naruto]

Hi. Normally, I would use a repository class/object to abstract all database calls and also to provide a sweet, type-safe API .