I've found what was causing all records to be deleted when a single
record is chosen.
SQL statement logging showed that clsql was generating simple "DELETE
FROM tablename" statements, whereas they should have a " WHERE id =
1234" -type clause.
The cause was that the ID slot in definition in def-view-class MUST
have a
:db-kind :key
slot option. Mine didn't.
It makes sense, but the implication seems to be that for the framework
to work with SQL databases, every table needs a single ID key field,
no matter whether it has one, many, or no natural keys.
On Apr 2, 8:23 pm, "Leslie P. Polzer" <[email protected]> wrote:
> On Apr 2, 4:47 am, Chris Hallwright <[email protected]>
> wrote:
>
> > So it's clearly something in the blog example different from the
> > weblocks-clsql-demo that's causing the problem with clsql back-ends.
> > This should help narrow the search considerably.
>
> I suggest enabling statement logging on your Postgres server and
> checking
> what exactly happens on an SQL level when the erroneous delete is
> launched.
>
> You can also compare the working gridedit from the demo with the
> erroneous simple-blog gridedit on an SQL level.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
