Re: Slot accessing issues in EIEIO

[Jonas Bernoulli <jonas@bernoul.li>]

I had not seen this reply of yours before I wrote my reply to an earlier
message a few minutes ago.

>> In this defclass definition. slots prefixed with "closql-" was reserved for
>> internal usage. and other slots present the columns in SQL database.
>
>> Obviously, accessing a slot in these definitions is valid. For example,
>> accessing slot "foobar" in that object will trigger real slot-missing method
>> because our definitions don't contain it. And accessing slots will trigger a
>> sync operation between Emacs VM and SQL database.
>
> [ By "VM" I assume you mean just the Emacs process, right?  ]
>
> Can you point me to where/how/when the "sync" operation is done
> (e.g. how does Emacs know when the SQL database is modified?  Is the
> whole database mirrored during the sync or only a whole column or only
> a specific element of a specific column or something else?).

For read operations there might be no sync at all.

When setting the value of a slot, then only that gets synced to the
database.

There is no guarantee that the database has not changed.  This can be an
issue and one should either avoid writes or be careful about it.

In the case of the Emacsmirror's database, e.g. the of `epkg-package'
objects, this isn't much of a problem because only I am supposed to
write to that database.  Users of `epkg' ("browse the Emacsmirror
package database") and `borg' ("assimilate Emacs packages as Git
submodules") are not supposed to modify the database (or the objects).

I have started using `closql' for `forge' ("Access Git forges from
Magit") as well, and here it is not without problems each user has their
own database which they obviously have to write too.

`closql' is definitely not a silver bullet.  It works nicely for what I
designed it for.  It works well enough for me, its author, in another
context, but I have no idea how well it would work for others for tasks
I did not consider.

>> When we put the sync logic in slot-missing.  How to distinguish really
>> missing slots and "simulated slots" is a problem.
>
> The way I'd imagine it is that you'd have 2 objects, one that's a sort
> of cache of the DB which could have slots like those listed in the `(defclass
> epkg-package` of epkg.el, and another on top (or in front of it) which
> is the one that's exposed to the rest of the code and this one only has
> closql-internal slots, so `slot-missing` is always triggered for
> simulated slots (and it can either answer by looking up
> the slot value in the cache object, or fetch the answer from the
> database and maybe store the result in the cache object).

That sounds too complicated for my use-cases at least, and I don't see
what we gain by doing that except not having to advice `eieio-oref' and
`eieio-oset', which by the way I don't think is all that horrible.

Sure, instead of

   (defun eieio-oset--closql-oset (fn obj slot value)
     (if (closql-object--eieio-childp obj)
         (closql-oset obj slot value)
       (funcall fn obj slot value)))

   (advice-add 'eieio-oset :around #'eieio-oset--closql-oset)

   (defun closql-oset (obj slot value)
     ...)

I would have liked to write

   (cl-defmethod eieio-oset ((obj closql-object) slot value)
     ...)

which, by the way is what I suggest we make possible.

I haven't gotten around to ask for the latter so far because as long as
`closql' supports older Emacs releases it would have to keep doing
something like the former for their benefit anyway.