I’m currently planning a proof of concept Phoenix web application, which should utilize CouchDB as its main database. I’ve some experience with CouchDB and I understand how to model the documents for my application.
Now, my main problem is how to handle user inputs. When users submit a form, all parameters are just strings. With ecto it’s quite simple as we can use a specific schema to cast these inputs to the correct data types e.g. integers, floats etc. But how to handle this without ecto? I need to cast user inputs to a struct, with the correct data types, which can be used within the application and to store (encoded to JSON) within CouchDB.
One option is to (ab)use a ecto schema for casting an validating the user inputs. But are there other options I can use? I’m searching for a couple of days but I don’t find anything suitable. Mostly some proof of concepts like “Parse, don’t validate”, which describes (mostly in theory) how to tackle this problem.
That would be my first attempt honestly. Once you have a changeset you can write your own logic for persistence. And schemas are useful anyway.
Or you could use a library like Xema. But for example you will still have to cast string-integers to integers, which means that you will have to validate those with custom validators or regexes.
I did not read the entire article you linked but to me validating before inserting makes no sense anyway. Just “validate” right after receiving the data (welll … the input) should be enough.
Ecto has been purposefully split into ecto and ecto_sql. So it’s definitely not an “abuse” to use Ecto simply for handling and casting user-provided data when you’re not working with an SQL database.
You can use all the lovely features of Changesets including integration with Phoenix, even if you’re using your own persistence layer.
I’ll echo the other messages. It is not abuse to use ecto without persistence. I gave a talk a couple of years ago “Ecto Without a DB” that has an example of validating user input for search params. Here’s the video queued to that section.
