I’ve been playing around with some “ORM” ideas for a bit in different ways, trying to find a good balance of “not-too-magical”, but still useful.
I feel the design has finally come together well enough that I’d like to invite people to give it a try.
Strapping.jl, which stands for Struct Relational Mapping, is a kind of serialization/deserialization package for converting objects and lists of objects to 2D “relations” or tables. ORMs are popular in lots of languages and have many different approaches for converting between application objects and database tables. Strapping.jl takes, as I mentioned, a very not-too-magical approach, yet still tries to be useful. It relies on the powerful Tables.jl and StructTypes.jl interfaces to provide two useful functions, Strapping.construct, and Strapping.deconstruct.
Strapping.construct(T or Vector{T}, table_source): takes any Tables.jl-compatible source (like the result of DBInterface.execute), and converts to a T or Vector{T}, using the StructTypes properties defined for T
Strapping.deconstruct(x::Union{T, Vector{T}}): takes an object instance or Vector of objects, and “deconstructs” the objects as a Tables.jl-compatible row iterator, which can then be used to store in a DataFrame/csv file, database table, etc.
Anyway, check out the docs for detailed examples/information and take it for a spin and let me know if you run into any issues.
I like where this is going: StructTypes.jl provides an extensible base API, and users get this functionality for (almost) free, independently of the backend. This would provide great synergy between a lot of packages.
I haven’t used orm for several years. Off-topic but does this have any thing related to database migrations, (which was the only thing that orm systems impressed me)?
Indeed; I originally had this package depend on DBInterface.jl and was very database-specific w/ SELECT queries, but as I mulled it over some more, I realized there wasn’t really anything database-specific about the functionality; I really just want a semi-automated way to serialize/deserialize structs to tables.
While some ORM solutions in other languages (and even SearchLight.jl in Julia) sometimes include functionality for automatically doing migrations and such, that’s always felt on the “too magical” side of things for me. Migrations in production are always scary enough, I would never feel comfortable with a solution that tried to take care of things too much for me.
In short, no, Strapping.jl doesn’t do any kind of migrations, and doesn’t even depend on any database packages. I think having migration capabilities is certainly useful, but in my mind, it’s a different set of functionality and concerns than the “struct serialization/deserialization” piece that Strapping.jl currently focuses on.
Not really. The difference might not be obvious, but I’ll try to clear it up:
JSONTables.jl allows you to turn raw json inputs into Tables.jl-compatible sources and vice versa: turn any Tables.jl source into valid raw json you can save in a file or send to a webservice or whatever
Strapping.jl, on the other hand, is about turning custom julia structs into Tables.jl-compatible sources (Strapping.deconstruct), and taking Tables.jl-compatible sources , and turning them into custom Julia structs (Strapping.construct).