Add slots to DB table classes
oberstet opened this issue · 4 comments
The DB table classes currently lack slots (as in eg https://github.com/crossbario/autobahn-python/blob/5b3f28549f48fc0f3df54512dd6a2eb1826fbcd2/autobahn/wamp/message.py#L540).
We should use slots - part of the reasons is that it avoids accidently setting a non-existing attribute
Adding slots is a bit of a challenge here. for each property we set a "private" counterpart of it. So for a property timestamp we have a _timestamp that gets set to None in the constructor. Then the setter for timestamp also assigns to that internal property. So we would need to add both _timestamp and timestamp to the __slots__ tuple.
@oberstet is that desirable/expected ?
Good question! In a way, the general question actually is:
How to combine
- (writable) properties
- slots
- type hints
in Python, and if that is useful / desirable in the first place. Let's first find the answer to that ..
Is the point of the _timestamp with @property versions to enforce "it must be of type X" when setting..? (e.g. here
cfxdb/cfxdb/eventstore/event.py
Line 41 in edf5603
the reason to have both _attribute and @property is so that _attribute is lazily caching the actual value from the DB as a python native type (on first access)
rgd the specific domain of walltime/timestamps (the example you linked): this has evolved in xbr db classes to:
that is, accessing offers[txn, offer_oid].timestamp returns a native np.datetime64 python object that will be stored in object._timestamp upon first access.
there have been a handful reason why it has evolved into that (could expand if of interest) .. the example you linked is not xbr, but from event store (wamp event persistency), and this predates the xbr stuff where "timestamp" has evolved. another example is UUID - also #38