On 6/14/06, James M Snell <[EMAIL PROTECTED]> wrote:
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
The work still happened to recognize what you wanted to store and what you did not, it just happened in ParserFilter. Something saw a QName it didn't want and dropped it. Your argument is really about the ability/right of servers to silently ignore, not the work/effort involved. It's fine to argue on that basis, but let's not obsfucate it as a performance argument. The work to segment the input data into the bits you are interested in and the bits you are not is still happening, its just happening up front.
