Support collections (seq/set)

[dom96]

This is a really awesome library! Thank you for putting it together.

One immediate thing I've tried is an object that contains a set[EnumType], would love it if this worked out of the box.

[moigagoo]

Thanks for the kind words, they really mean a lot to me 🙏

Are you suggesting mapping Nim enum type to Postgres enum? How should it be handled in SQLite?

[dom96]

I'm suggesting you should support sequences and sets. Guess this would require creating a hidden extra table.

[moigagoo]

Oh, you mean one to many relations represented? I thought about it but decided to keep models close to table schemas, so you define one to many with foreign keys as you would normally do in a table schema.

However, Norm may be mature enough to provide a nicer interface for one to many relations. What if we add a proc that returns a seq if objects to types which are referenced as foreign keys in other types? Something like getMany that accepts two types, the "one" type and the "many" type.

[moigagoo]

Nvm, I think I understand your proposal well enough now, my comment suggests a totally different story.

[EchoPouet]

Hello, thanks for your library.

Will the seq be implemented soon ?

[moigagoo]

Unlikely. Because I don't have a clear understanding how to represent seqs in SQL. Serializing and deserializing them sounds very expensive. And what if it's a seq of Model? How do I retrieve it from the DB?

[EchoPouet]

I understand, it's certainly not easy. A co-worker use Pony (Array https://docs.ponyorm.org/array.html) with Python. Maybe the code can help you. I hope :)

[moigagoo]

@ArMour85 thanks for the link. I like Pony a lot and drew some inspiration from it (in fact, you can spot my quote on their website 🙂).

They seem to have special types for collections that can be stored in DB. I guess we could go this path and add support for seq[SomeNumber] and the likes and store them as serialized json in SQLite maybe. In Postgres, there's a type for that (there's a type for everything apparently).

[ajusa]

This might be a bit off topic from the issue, but what I would like to see is handling an enum based field. Internally, this could map to just an integer (which means that reordering the enum fields would break stuff). Then, it would be really cool if you could query based on a set of enums.
So, if I had an enum {online, disconnected, awake} and I wanted to get users who are online and disconnected, I could somehow pass in a set ({online, disconnected}) of possible states and have it generate a query that looks something like state = 0 or state = 1).

This might not be something you want within norm though - and that's fine - just thought I would throw it out there.

[PhilippMDoerner]

@moigagoo @dom96 @ajusa
I think with the merging of earlier PRs from me we have passable support for one-to-many and many-to-many relationships now. You need to go through specific procs admittedly, but imo it works and has the benefit of making you more aware of querying such relationships.

If I'm understanding it right, that was the main point of the issue, right?
There has emerged a second issue though, that being supporting storing multiple values in a single column (e.g. multiple enum values). Did I understand that one right ajusa?

I'm not 100% sure since I didn't try that one yet, but wouldn't this already be possible by defining a type alias and defining dbType, dbValue, and to procs for it (I realize now that that should definitely be documented in norm's docs... that might be worth making an issue for).

Given that, wouldn't it make sense to close this issue?