I’m fairly new to Rails and decided I wanted to give it a go for a
fairly simple internal application that I want to refine and use it as
the building blocks for possible future applications.
The application will act, for now at least, as webservice API used by
external applications to POST and GET data. After watching DHH 2006
Rails conference talk I liked the fact that you could use one piece of
code with different interfaces. However I feel like I’m coming up
against difficultly modeling my domain and the interaction with the
external application yet still allowing room for a web interface if
required down the road.
Essentially what we have are error reporting applications out in the
field where those applications are tied to a specific location. The
application knows its location and what it is, it looks to use that
information to post an error report. The current php version of this
application simply posts the data as an Error Report. Doing so kicks
off a trigger that inserts into a summary table if the application and
location doesn’t exist.
With that in mind Here is my current vision for the model.
Location (1) --> (1 … *) Application (1) --> (0 … *) Error Report
The problem is a new location and application can come online without
being placed into the database prior to reporting an error. Thus the
question is, should the external reporting application check to see if
its Location and Application exists in the database first by
searching, then creating new Location and Application records if
required and then POSTing the Error Report? That seems very verbose.
It would be nice to simply POST the error report and if required the
related data objects created.
- Is this possible?
- If it is possible would it be considered bad practice to have the
creation of a resource create other resources?
- Might there a better way to solve this problem that I just can’t