dm:field barfs on nil input

[Davidbhodge]

When query returns a null response dm:field barfs with the following

There is no applicable method for the generic function

<STANDARD-GENERIC-FUNCTION DATA-MODEL::FIELD-TABLE (1)>

when called with arguments (NIL). [Condition of type SIMPLE-ERROR]

This is undesirable behaviour for normal operations. For the moment I have wrapped call to dm:field to catch null responses and use a handler-case to deal with the situation., where I have it return sensible results - a 404 when called through an api or nil when called server side.

ideally, dm:field should handle this, and there should probably be a number of standard conditions - empty-set, sql-error etc which could then be handled by the client program.

[Shinmera]

dm:field is an accessor on a particular data structure, namely a data-model. Making it not barf when you don't pass it that data structure is the kind of magic coercion stuff that I consider actively harmful.

To do what you seem to want, you'd simply use something akin to (dm:field (or (dm:get-one ..) (error 'request-not-found))). Typically, though, you don't just access a single field from a record you retrieved, and thus the pattern is more akin to (let ((model (or (dm:get-one ..) (error 'request-not-found)))) ...). But then you probably want to encode the logic of how you retrieve the record into a function, and thus encapsulate the erroring into that function as well, turning the above into (let ((model (ensure-thingy ..))) ..). This is what I already outline in the tutorial as well.

There are already standard conditions for most database related errors. See the interface definition. For anything not explicitly covered by this, the conditions are implementation-dependant.

A case could be made for dm:get-one to error on an unfound model instead of returning NIL, but I consider both to be acceptable behaviour and don't see any real reason to suddenly start breaking compatibility.

[Davidbhodge]

Hi,

Here is the use case - the user is entering data into a type ahead field. I am interested in just a single field.

The typeahead javascript thingy ( and I am really begining to hate javascript) will issue a query to my backend service - if the query finds candidate completions great, if not then something new is being added . We can't know exactly what until the form is submitted. An (ensure-thingy) in this case can only return nil.

It might be that i just don't use the dm component for this particular usage, though for the moment the scheme I have works well enough. There are a least several dozen typeahead fields throughout the application so its important to get the underlying mechanics right for both usability and reliability.

I will look through the definitions again - there is a lot for me to to grok still.

Cheers

Nicolas Hafner mailto:notifications@github.com 13 October 2017 at 10:19 AM

|dm:field| is an accessor on a particular data structure, namely a |data-model|. Making it /not/ barf when you don't pass it that data structure is the kind of magic coercion stuff that I consider actively harmful.

To do what you seem to want, you'd simply use something akin to |(dm:field (or (dm:get-one ..) (error 'request-not-found)))|. Typically, though, you don't just access a single field from a record you retrieved, and thus the pattern is more akin to |(let ((model (or (dm:get-one ..) (error 'request-not-found)))) ...)|. But then you probably want to encode the logic of how you retrieve the record into a function, and thus encapsulate the erroring into that function as well, turning the above into |(let ((model (ensure-thingy ..))) ..)|. This is what I already outline in the tutorial as well.

There are already standard conditions for most database related errors. See the interface definition https://shirakumo.github.io/radiance/#DATABASE:CONDITION. For anything not explicitly covered by this, the conditions are implementation-dependant.

A case could be made for |dm:get-one| to error on an unfound model instead of returning NIL, but I consider both to be acceptable behaviour and don't see any real reason to suddenly start breaking compatibility.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Shirakumo/radiance-contribs/issues/4#issuecomment-336274161, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjLlolhqCIBAgW_UfEG-IPpp-O435Mtks5sroJkgaJpZM4P3ndp.