peerreynders
OvermindDL1
peerreynders
As in OO class:
Mediatable is representative of an abstract base class and becomes the primary table holding the common fields and dictating the primary key.Video,Image,Markdownare representative of concrete (derived) classes which map to tables which referenceMedia. They contain the records holding the class (type) specific fields.
jdumont
I think this is part of where my confusion stems from. Modelling this (for a DB at least) becomes very OO very quickly.
@peerreynders are you suggesting that this pattern is inadvisable because of my “class” being split over two tables?
At what point is a struct or Ecto schema considered a class?
EDIT: Further question, putting aside the DB for a moment, what’s the most idiomatic way of modelling this data in Elixir?
peerreynders
I was simply referencing “prior art”. The DB simply stores the relevant instance properties - so in this context there is no real difference between a class or a structure.
The challenge isn’t really modelling it in the DB - but determining the best way to exploit that physical data model within Ecto if you need to use changesets because ideally you just want a flat Video, Image, Markdown structure (if you are just querying there is no problem) rather than having to deal with a nested Video, Image, or Markdown struct inside a Media struct.
Ultimately 2.1 Map Hierarchy To A Single Table is the easiest to accomodate within Ecto. Right now I’m not familiar enough with all aspects of Ecto to find the best way to make Map Each Class To Its own Table work - if you need to use changesets.
jdumont
I think this is where the problem shows itself. Regardless of how it’s best to model it within the database (when considering query speed, normalisation, etc or just plain “rightness” where it’s logical), modelling it as a single table with lots of different columns, many unused for a given media type is the easiest approach because its what Ecto will most easily allow for.
I think any other approach forces you to reconsider how Ecto fits. If you’re fighting it, or at the very least trying to work around the “one schema = one table” concept, then you are probably better off without it. That’s a big trade off to consider vs some empty columns in a table.
That brings me back to where I ended up with my CrossFit app (recursively nested Ecto structs - although that recursion brought its own complexity). Ho-hum, there’s rarely a single “right” answer is there? 
OvermindDL1
Actually Ecto models it as links very well, that’s what the whole has_one/belongs_to and so forth is for. 
jdumont
But when loading all the media records for a document, I’d have a Media struct for each with a nested Image, Video, whatever struct.
Or have I misunderstood?
peerreynders
Focusing on this statement in particular I’m not convinced you are dealing with a polymorphic entity in your domain.
This simply states that you need to show them in the same list - so it may be enough to have a Content table which identifies (document and) type (inferring a distinct table) and a key into that table.
How much information do you need to grab on this query?
OvermindDL1
Huh? No?
You’d just have a schema for each link, mapping to the tables directly most easily.
Honestly I rarely if ever do that, I use schemas to just get what I want and use a query to build it up linking it all within the query itself, but I’m a lot more comfortable in SQL than most. ^.^;