-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider Object Approach for DB Sources #18
Comments
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 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. |
I agree that the final output that users get should be of type 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. |
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.
The text was updated successfully, but these errors were encountered: