unique ids
Daniel Brooks
information about the intended way of giving all the objects I'm storing
a unique ID. This might be purely a cl-prevelance question though.
I'm deriving my objects from cl-prevelance's object-with-id class, and
I've overridden class-id-slot-name so that weblocks can figure out the
id of the objects I'm storing and retrieving. However, everything has an
id of -1, which is obviously wrong. Has anyone seen this before? Am I
skipping a step? From what I could tell, cl-prevelance should be doing
all the work for me, keeping the next available id stored in it's
database somewhere, but it doesn't seem to be doing so.
db48x
Leslie P. Polzer
From the Prevalence sources:
(defclass object-with-id ()
((id :reader get-id :initarg :id :initform -1))
(:documentation "Superclass for objects with an id"))
Weblocks assigns an uid when you call PERSIST-OBJECT.
Leslie
Daniel Brooks
And apparently the form view is calling that from
update-object-view-from-request, right? The objects are certainly being
persisted; any new objects that I try to create end up overwriting the
first (because they have the same id.)
db48x
Leslie P. Polzer
Daniel Brooks wrote:
> And apparently the form view is calling that from
> update-object-view-from-request, right? The objects are certainly being
> persisted; any new objects that I try to create end up overwriting the
> first (because they have the same id.)
I've looked at the code.
You can't use object-with-id with Weblocks-Prevalence because
it initializes the id slot with -1. Use your own object-with-id
class that initializes the slot with NIL or doesn't bind it at all.
Daniel Brooks
Ah, ok. This should be made more uniform, it seems like it works
differently for each of the storage back ends.
Thanks
db48x
Leslie P. Polzer
Daniel Brooks wrote:
> Ah, ok. This should be made more uniform, it seems like it works
> differently for each of the storage back ends.
I totally agree. The current store API and semantics need an
overhaul.