railsmechanic
Hi!
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.
Do you have any hints for me?
Many thanks!
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
lud
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.
wmnnd
Ecto has been purposefully split into
ectoandecto_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.
gregvaughn
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.