We do need to make sure we have a good pagination strategy in place for this though.We only have to query one table rather than doing joins.Lets loop back on the original goals we had set for ourselves to see how we measure up. Instead we will define a polymorphic type.ĭefmodule TransactionFeedItem do use Ecto.Schema alias Ecto.Changeset schema "transaction_feed_items" do # shared fields field :amount, :decimal # polymorphic field field :data, PolymorphicType, interest : InterestEarnedTransaction, card : CardTransaction end def changeset ( % _MODULE_ Įlixir you never cease to amaze me! Did we make it? # They probably have some sort of schema, just not one we can enforce at the database level. For one, our unique transaction types are not just loose key value pairs. We could just define it as a :map and call it a day but there are some issues with that. Next, we need a way to have a field that can be any one of our transaction types. It feels safe to assume every transaction would have an amount so lets just go with that. We don’t want to be too aggressive on deciding what fields are shared between all records since we want to support unknown transaction types down the road. For all other fields we will use our polymorphic type. For all the fields we can confidently say will be on every record we will make columns. This one table will house all of our transaction records. To start our adventure we will need to create a schema for our database table. There are always tradeoffs and alternatives - I’ll discuss those briefly at the end. Use the Ecto patterns we already know and love. New activity items can be added to the feed without needing changes to the database or hurting performance.Each transaction line item has its own enforceable schema.Querying the transaction feed is performant and scalable.We are using a SQL database that supports maps - I’ll be assuming Postgres.Goals and Requirements #īefore we dive into the code lets fully flesh out the requirements so that we can build our solution around them. On interest earned events there would be, well, interest earned amounts. On a card transaction you would expect to see merchant details. While they represent a financial transaction, each one has unique details to it. It’s tempting to want to group these things together and call them “transactions”. In this feed you want to show a list of user transactions - things such as deposits, transfers, card transactions, and interest earned events. You are implementing an activity feed for the hottest Fintech startup in the valley. How often has this happened to you? You are using a SQL database and need to model a collection of conceptually similar items that all have a slightly different shape? Let’s give a concrete example. Parameterized types landed in Ecto 3.5 and with them some new magical powers for us alchemists.
0 Comments
|