Hi David,

> I'm fumbling through some tests trying to get an understanding of how to
> insert and retrieve database objects:

Good! :)


> (class +Cls +Entity)
> (rel id (+Need +Key +String))
> (rel val (+Need +String))
> (dm T ()
>    (=: id (pack (in "/dev/urandom" (rd 5))))
>    (=: val *Val) )

Using the low-level '=:' function is not suitable for Entities, because
it doesn't take care of side efffects like maintaining indexes. Instead,
'put>' should be used:

   (dm T ()
      (put> This 'id (pack (in "/dev/urandom" (rd 5))))
      (put> This 'val *Val) )

> : (new! '(+Cls))
> -> {2}
> : (show '{2})
> {2} (+Cls)
>    val "value"
>    id "701131216474"
> -> {2}

As you see, the object was correcly created, but

> : (collect 'id '+Cls)
> -> NIL

doesn't return anything, because the indexes for 'id' and 'val' were not
maintained.


If you use 'put>' as above, you'll get:

   : (collect 'id '+Cls)
   -> ({2})


> : (select '+Cls)
> <picolisp goes into a loop>

Note that 'select' does not evaluate its arguments, so it should
be called without quotes:

   : (select +Cls)
   {2} (+Cls)
      id "333619022780"
      val "value"
   -> NIL


BTW, for entities it is usually not necessary to write an explicit 'T'
method, as that class already has a rather useful one. Instead, you can
simply pass the values to 'new' or 'new!':

   (pool "test.db")

   (new! '(+Cls)
      'id (pack (in "/dev/urandom" (rd 5)))
      'val "value" )



One more note about '+Need': I observe that most people end up putting
the '+Need' prefix into almost every relation. This is not recommended.

'+Need' causes the GUI to complain if the value is missing. However,
this can put the user into trouble if more than one field is "need"ed
and he starts up with an empty object. He'll not get the chance to enter
values, because already the first field will complain about the other
empty fields.

So my rule is: Use '+Need' only for relations which are pre-filled by
the system when creating the object, like incremental object numbers.
Then the user can only change but not clear the value.

For other relations, better write dynamic integrity checks in the GUI
upon certain actions (button presses), when the data are actually needed
and processed.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
  • Database David N Murray
    • Re: Database Alexander Burger

Reply via email to