Consider Object Approach for DB Sources

[dr-rodriguez]

Instead of treating everything like a dictionary, perhaps it would have been better to implement Python Classes for the various types of objects we are considering- Sources, Fields, Entries, Values. Then I could have methods that properly format it to/from JSON and that independently validate without having to rely on crawling through a dictionary. Could make local searching more complicated, but I would favor rewriting it with this data model in mind as it would make things more manageable as the API grows in complexity.

[eteq]

My initial instinct is that this adds a lot of complexity with questionable value for the user. In the end the user is really going to want Quantity and array objects anyway, so I think it's better to focus the user-facing API on getting quickly to those sort of objects.

That said, if we're thinking of this more as an "implementation detail", or using this as a way to implement a relatively light ORM-like model, I could see that. But I think we then have to be very careful to not spend too much time thinking of this as the "normal" interface.

[dr-rodriguez]

I agree that the final output that users get should be of type array, Quantity, or similar. In my mind, this is meant more as the low-level API behind the scenes to facilitate queries, validation, etc.

Currently, the (local) database is implemented as an array of dictionary objects and while dictionaries are very powerful, I feel that they also have some drawbacks. A lot of the code is wrangling with these dictionaries to get the functionality we want out of them and enforce our validation, something that might be possible to simplify by having some enforced structure.