<commit_before>TODO
====

Allow raw importing of JSON, without the serialization step.  In
fact people could just do this with PSQL and then we could get free
lisp objects from it!

I could wrap the serialization failure condition and send a nice
message to the user...  Maybe I wrap *all* Postmodern conditions and
tell them the abstraction has leaked...?  Given the range of Postmodern
conditions it may be possible to handle some sensible subset...

unique ids from UUID example

Stash valid_to, valid_from in objects from get-all?

* Support querying of jsonb columns through Postmodern:

```sql
select c.jdoc->'name', c.jdoc->'coat', d.jdoc->'coat'
from cat c
join dog d on (c.jdoc->'name' = d.jdoc->'name');
```

* Rethinkdb query to emulate

```common-lisp
(def-query-vector approved-orphaned-extra-charges (booking-ids) ()
  (re:r (:map (:eq-join (:map (:eq-join (:filter (:get-all (:table "extra_charges")
                                                           booking-ids
                                                           :index "bookingId")
                                                 (re:fn (extra-charge)
                                                   (:&& (:== "orphaned" (:row "state"))
                                                        (:row "approvedP"))))
                                        "typeId"
                                        (:table "extra_charge_types"))
                              (re:fn (row)
                                (:merge (:row "left")
                                        {o "type" (:attr (:row "right") "type")})))
                        "bookingId"
                        (:table "bookings"))
              (re:fn (row)
                {o "left" (:row "left")
                   "right" (:merge (:row "right")
                                   {o "orphanParent" t})}))))
```

* Bulk inserts, clearly a need.

* stash-id is expecting a hash table - test and document

* Make using Fkeys between tables easy...

Test behaviour of nil, false, empty array etc on to-json, from-json
etc.  Different libraries, different results.

Would be nice to lisply abstract the JSON select stuff from PG.
Of course, you can still go to the DB directly if you like.

Compound primary keys shoudn't be too hard. We make it either an ordered
list or a map.

The model parameters could have a a single reader fn by string and
then we wouldn't need the entire fleet of specials!

How is our global query functions hash table cache affected by the use<commit_msg>Add a TODO on ID to KEY name change<commit_after>TODO
====

Allow raw importing of JSON, without the serialization step.  In
fact people could just do this with PSQL and then we could get free
lisp objects from it!

I could wrap the serialization failure condition and send a nice
message to the user...  Maybe I wrap *all* Postmodern conditions and
tell them the abstraction has leaked...?  Given the range of Postmodern
conditions it may be possible to handle some sensible subset...

unique ids from UUID example

Stash valid_to, valid_from in objects from get-all?

* Support querying of jsonb columns through Postmodern:

```sql
select c.jdoc->'name', c.jdoc->'coat', d.jdoc->'coat'
from cat c
join dog d on (c.jdoc->'name' = d.jdoc->'name');
```

* Rethinkdb query to emulate

```common-lisp
(def-query-vector approved-orphaned-extra-charges (booking-ids) ()
  (re:r (:map (:eq-join (:map (:eq-join (:filter (:get-all (:table "extra_charges")
                                                           booking-ids
                                                           :index "bookingId")
                                                 (re:fn (extra-charge)
                                                   (:&& (:== "orphaned" (:row "state"))
                                                        (:row "approvedP"))))
                                        "typeId"
                                        (:table "extra_charge_types"))
                              (re:fn (row)
                                (:merge (:row "left")
                                        {o "type" (:attr (:row "right") "type")})))
                        "bookingId"
                        (:table "bookings"))
              (re:fn (row)
                {o "left" (:row "left")
                   "right" (:merge (:row "right")
                                   {o "orphanParent" t})}))))
```

* Bulk inserts, clearly a need.

* stash-id is expecting a hash table - test and document

* Make using Fkeys between tables easy...

Test behaviour of nil, false, empty array etc on to-json, from-json
etc.  Different libraries, different results.

Would be nice to lisply abstract the JSON select stuff from PG.
Of course, you can still go to the DB directly if you like.

Compound primary keys shoudn't be too hard. We make it either an ordered
list or a map.  Also change name of ID to KEY to suit.

The model parameters could have a a single reader fn by string and
then we wouldn't need the entire fleet of specials!

How is our global query functions hash table cache affected by the use
{'fraction_non_alphanumeric': 0.093798751950078, 'fraction_numerical': 0.0, 'mean_word_length': 1.6881551362683438, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 30, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4363359', 'n_tokens_mistral': 1334, 'n_tokens_neox': 1241, 'n_words': 566}