Kyle Marvin wrote:
>[snip]
> I don't understand James relational DB-exposed-as-Atom example. If I
> try to set a column that a DB can't match to the underlying schema
> using SQL, I get an error. Why woudn't I expect the same if I did so
> via an Atom mapping over SQL relational data?
>
> Wouldn't you parse the input data for the bits you do persist (to
> store them) and isn't it possible to recognize that there are
> exceptions? Is there really extra work there?
>
In one of our implementations, the only metadata in the entry that is
actually editable is the content, the title and the categories.
Currently, when we receive an entry on PUT, we pull out only the bits we
care about and ignore everything else. If there are unknown extensions
in the entry, we don't care, we never see them, they are silently
ignored. Adding a constraint that we must reject entries that contain
stuff we can't store means that we can no longer silently ignore them.
We have to explicitly go in and look to see if there is anything we
can't store rather than going in and just pulling out the bits we care
about. Yes, there's extra work and extra resources that we simply have
no need to allocate. [1]
- James
[1] http://www.snellspace.com/wp/?p=355
> Honestly, I'm not religious about this issue, but I'd feel better if
> someone gave me one real world use case that I could get my arms
> around.
>
> -- Kyle
>
