On 14 November 2013 17:55, Brian Craft <craft.br...@gmail.com> wrote:
>
> On Thursday, November 14, 2013 9:17:32 AM UTC-8, James Reeves wrote:
>
>>
>> For instance, database migrations. This was something I thought about a
>> lot a few years ago, until I gradually realised that I wasn't finding
>> myself in any situations where I needed them.
>>
>
> I don't really understand this argument. What database tables would we not
> require if we used clojure? User passwords? Page content? User settings?
> Admin privileges? Of those tables, which ones would we not need admin
> interfaces for if we used clojure? I don't understand how choice of
> framework has any bearing on what data the app must store, what admin
> interfaces are required, what validation layers must be present, etc. You
> must validate all the user input. You must store all the data required by
> the app. You must have admin backends for all of the data used by the app.
> Using clojure doesn't change any of those requirements.
>
> And when we have changes to the data model, for example when finding that
> a new feature requires that we track an additional field for each user, or
> finding that a new clinical data set requires a more complex model of
> clinical samples, how would clojure allow us to avoid migrating the data
> model in the database, or update the model in a reliable way across several
> installs without using migrations? Again, I don't understand how the
> framework has anything to do with the necessity of updating a data model
> when new features or new data demand it.
>
SQL databases complect a number of different ideas about data, and this
complexity results in certain problems.
Database migrations, for instance, are a symptom of a system where data
storage is tightly coupled to grouping and validation of data. In systems
which separate data storage from data indexing and viewing, migrations
cease to be something you need.
Let's assume that we're measuring the heart rate of subjects for a clinical
trial. We might have a data structure that looks like this:
{:timestamp #inst "..."
:subject/id #uuid "..."
:subject/heart-rate 80}
Let's further assume that we're only going to deal with *storage* and
*ordering* for this data. So we're going to maintain an atomically updated
log of incoming data from patients.
We now want to *index* this data in some fashion, to display the results in
a table or a chart. This can be done by taking the data from the log, and
copying it to a read-only database that supports querying and aggregation.
The data could be copied over in bulk periodically, or pushed in real time.
After some time, the requirements for our system change, and we now have to
record heart-rate at rest and during exercise. Because we don't want to
complect the data by prematurely grouping it, we instead introduce two new
types of data structure:
{:timestamp #inst "..."
:subject/id #uuid "..."
:subject/hr-rest 80}
{:timestamp #inst "..."
:subject/id #uuid "..."
:subject/hr-max 180}
We then update our indexing algorithm, so that it now indexes two different
heart-rates. We might also choose to make :subject/heart-rate equivalent to
:subject/hr-rest. Instead of migrating this data, we can just regenerate
the database from scratch from the raw data.
Essentially we're doing away with a data model altogether, and replacing it
with a log of isolated, immutable data entries combined with a set of
disposable, read-only views.
Django's admin interface is nice, but it's still tied to the idea of having
a monolithic, complex and mutable database. The benefits of working with
isolated, simple, immutable data aren't worth giving up for that.
- James
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
