I'm making a library for heterogeneous, strongly typed records.
Here's my work so far. It has some operations for working with tuples (named or unnamed), allowing you to concatenate and rearrange them.
I also introduce the Record type, which is a tuple minus the ordering of fields. Two records are the same if they have the same values in correspondingly named fields.
https://github.com/rotu/nim-records
Any feedback is welcome! I'm very new to Nim, so I might be badly abusing the language!
Interesting approach, I'm curious to read through your code a bit more.
Also I found the variant library to be really handy for similar cases. It might provide you some inspiration.
variant is pretty cool. I'm going for a totally different approach, as all my polymorphism is runtime, not compile time.
Some of the tuple stuff I'm doing seems more generally useful and maybe deserving of its own library:
This is really cool. It's great that stuff like this is possible and actually fairly simple to do in Nim.
Many packages have "tupleutils" style procs that would be nice to have collected in one place, but it might be too niche for the standard library. This package is still mostly unique, surprised I haven't seen a similar package before.
Thank you for your words of encouragement! I keep thinking when writing this code “surely someone must have written this already.”
So much of the “vertical” operations of relational programming has made it into the mainstream (filter, reduce, fold), probably because they have nice recursive definitions. So I’m exploring the horizontal (project, join, rename) which are basically impossible in many languages.
Nexus's ORM does this by generating data access procs.
Here's the YAML for Nexus Core models: https://github.com/jfilby/nexus/blob/main/conf/core/models/models.yaml
Here's one of the generated data access files: https://github.com/jfilby/nexus/blob/main/src/nexus/core/data_access/account_user_data.nim
Here's the generated model types file: https://github.com/jfilby/nexus/blob/main/src/nexus/core/types/model_types.nim
The model_types.nim file includes stringified types for non-string fields, but that's optional. The project is in active development: https://github.com/jfilby/nexus
Thank you for showcasing!
For me, fast prototyping is everything. Do if I have a YAML file that gets converted into CREATE TABLE behind the scenes, then I have to worry about how to write the YAML file in such a way to produce the CREATE TABLE statements I know I need. This is friction. I am much better off just writing the statements. Now already writing app and frontend code instead of wondering whether the SQL generator will support tuning my indexes.
I don't mean to knock your work, many people love ORMs and writing a good one is the hardest work in the world- so more power to you! (And your users).
To even consider using an ORM these days, it would need to be ablee to derive all generated code from hand-created database tables. Then it would have to additionally support creating arbitrary object tree structures from arbitrary SQL queries. I found that if you count debugging and quickly making modifications responding to user needs, flexibility- maximally detailed control- is the more critical factor than automation to get results quickly.
I've made some great progress on my records library!
In particular, I've added Table/Map-like operations and an implementation of Relational Algebra as operations on seq[tuple].
Although this library might be useful for building ORMs, that's not a current goal. All the relational operations are performed in Nim, not delegated out to some database.