Copyright (c) 2007-2022 gocept gmbh & co. kg and contributors.
All Rights Reserved.
This software is subject to the provisions of the Zope Public License,
Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
FOR A PARTICULAR PURPOSE.
============
Introduction
============
This package provides a reference implementation.
The specific properties of this implementation are:
- intended to be used for intrinsic references
- provides integrity enforcement
- modelled partially after relational `foreign keys`
.. contents::
Motivation
==========
When developing an application we often find the need to reference objects
that are stored as application data. Examples of such objects include
centrally managed 'master data'.
The reference to those objects is typically intrinsic to the application we
develop so they should behave like normal Python object references while being
under the control of our application.
Within the world of Zope and ZODB there are different ways to achieve this. The
various approaches have different semantics and side effects. Our goal is to
unify the way of intrinsically referencing objects and to provide the ability to
switch between different semantics as needed without rewriting application code
and without the need to migrate persistent data structures (at least from the
application's point of view).
Model comparison
================
Our goal was to determine the advantages and disadvantages of the different
existing approaches. We included three general approaches from the world of
Python/Zope/ZODB as well as the standard relational approach to normalisation
tables.
We used four criteria to describe each solution:
Reference data
What data is stored to describe the reference?
Reference semantics
What meaning does the reference have? How can its meaning change?
Integrity
What might happen to the application if data that is involved in the
reference changes or is deleted?
Set/Lookup
What does the application developer have to do to set a reference or
look up a referenced object?
====================== ========================================= =========================================== ======================================== ====================================================
Property Python references Weak references Key reference Relational DBs
====================== ========================================= =========================================== ======================================== ====================================================
Reference data OID OID application-specific key application-specific (primary key + table name)
Reference semantics Refers to a specific Refers to a specific Refers to an object which Refers to an object (row) that is associated
Python object Python object is associated with the saved key with the primary key at the time of the lookup.
at the time of the lookup.
Integrity The reference stays valid, however, The reference might have become stale The reference might have become Dependening on the use of `foreign keys`
the target object might have lost its and leave the referencing object in an stale. and the databases implementation of constraints.
meaning for the application. invalid state. Can usually be forced to stay valid.
Set/Lookup Normal Python attribute access. Use WeakRef wrapper to store and Depends on the implementation. Explicitly store the primary key.
__call__ to lookup. Might use properties Might use properties for convenience. Use JOIN to look up.
for convenience.
====================== ========================================= =========================================== ======================================== ====================================================
Observations
============
- Relational: every object (row) has a canonical place that defines a primary
key.
The ZODB (like a filesystem) can have multiple hard links to an object.
Objects are deleted when the last hard link to an object is removed. This
makes it impossible to use hard links for referencing an object because
object deletion will not be noticed and the objects will continue to live.
The ZODB itself does not have a notion of a canonical place where an object
is defined.
- Relational: When referencing an object we can enforce integrity by declaring
a foreign key. This is orthogonal to the data stored.
- Relational: As an application-level key is used for identifying the target
of a reference, the application can choose to delete a row and re-add a row
with the same primary key later. If the integrity is enforced this requires
support on the database level to temporarily ignore broken foreign keys.
- Normal Python references embed themselves naturally in the application.
Properties allow hiding the implementation of looking up and storing
references.
Conclusions & Requirements for the reference implementation
===========================================================
- Allow configuration of `foreign key` constraints (none, always, at the end
of the transaction). This configuration must be changable at any time with
an automatic migration path provided.
- Use application level keys to refer to an object.
- Use a canonical location and a primary key to store objects and to determine
whether an object was deleted.
- Distinguish between two use cases when modifying an object's key:
1. The application references the right object but has the wrong key (as the
key itself might have meaning for the application). In this case the
object must be updated to receive the new, correct key and the references
must be updated to refer to this new key.
2. The application references the wrong object with the right key. In this
case the object referenced by the key must be replaced with a different
object.
Implementation notes
====================
- Canonical location is determined by location/containment. The primary key for
a reference is the referenced object's location.
- Constraints are enforced by monitoring containment events.
- The different ways of updating/changing a key's meaning are supported by an
indirection that enumerates all keys and stores a `reference id` on the
referencing object instead of the location. The two use cases for changing
the meaning are implemented by:
1. associating a new path with an existing reference id
2. associating a new reference id with an existing path
===================
Referencing objects
===================
Simple references
=================
For working with references you have to have a located site set:
>>> import zope.component.hooks
>>> root = getRootFolder()
>>> zope.component.hooks.setSite(root)
For demonstration purposes we define two classes, one for referenced objects,
the other defining the reference. Classes using references have to implement
IAttributeAnnotatable as references are stored as annotations:
>>> from zope.container.contained import Contained
>>> import gocept.reference
>>> import zope.interface
>>> from zope.annotation.interfaces import IAttributeAnnotatable
>>> @zope.interface.implementer(IAttributeAnnotatable)
... class Address(Contained):
... city = gocept.reference.Reference()
>>> class City(Contained):
... pass
As instances of classes defined in a doctest cannot be persisted, we import
implementations of the classes from a real Python module:
>>> from gocept.reference.testing import Address, City
The referenced objects must be stored in the ZODB and must be located:
>>> root['dessau'] = City()
>>> root['halle'] = City()
>>> root['jena'] = City()
In order to reference an object, the object only needs to be assigned to the
attribute implemented as a reference descriptor:
>>> theuni = Address()
>>> theuni.city = root['dessau']
>>> theuni.city
<gocept.reference.testing.City object at 0x...>
It is also possible to assign `None` to let the reference point to no
object:
>>> theuni.city = None
>>> print(theuni.city)
None
Values can be deleted, the descriptor raises an AttributeError then:
>>> del theuni.city
>>> theuni.city
Traceback (most recent call last):
AttributeError: city
Only contained objects can be assigned to a reference that has
integrity ensurance enabled:
>>> theuni.city = 12
Traceback (most recent call last):
TypeError: ...
Integrity-ensured references
============================
>>> @zope.interface.implementer(IAttributeAnnotatable)
... class Monument(Contained):
... city = gocept.reference.Reference(ensure_integrity=True)
>>> from gocept.reference.testing import Monument
Located source
--------------
Referential integrity can be ensured if the source of the reference is
located:
>>> root['fuchsturm'] = Monument()
>>> root['fuchsturm'].city = root['dessau']
>>> root['fuchsturm'].city is root['dessau']
True
>>> import transaction
>>> transaction.commit()
>>> del root['dessau']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move
<gocept.reference.testing.City object at 0x...>.
The (sub-)object <gocept.reference.testing.City object at 0x...> is
still being referenced.
>>> transaction.commit()
Traceback (most recent call last):
transaction.interfaces.DoomedTransaction: transaction doomed, cannot commit
>>> transaction.abort()
>>> 'dessau' in root
True
To check whether an object is referenced, it can be adapted to
IReferenceTarget:
>>> from gocept.reference.interfaces import IReferenceTarget
>>> IReferenceTarget(root['dessau']).is_referenced()
True
>>> root['fuchsturm'].city = None
>>> IReferenceTarget(root['dessau']).is_referenced()
False
>>> del root['dessau']
>>> 'dessau' in root
False
XXX References will also be correctly cancelled when the attribute or the
source is deleted.
>>> del root['fuchsturm']
Non-located source
------------------
If the source of a reference is not located, we can do anything we want with
references, including breaking them:
>>> fuchsturm = Monument()
>>> fuchsturm.city = root['jena']
>>> fuchsturm.city is root['jena']
True
>>> del fuchsturm.city
>>> fuchsturm.city
Traceback (most recent call last):
AttributeError: city
>>> fuchsturm.city = root['jena']
>>> fuchsturm.city is root['jena']
True
>>> del root['jena']
>>> fuchsturm.city
Traceback (most recent call last):
gocept.reference.interfaces.LookupError: Reference target '/jena' no longer exists.
Changing the location state of the source
-----------------------------------------
We cannot put an object with a broken reference back into containment since
referential integrity is not given:
>>> transaction.commit()
>>> root['fuchsturm'] = fuchsturm
Traceback (most recent call last):
gocept.reference.interfaces.LookupError: Reference target '/jena' no longer exists.
The transaction was doomed, let's recover the last working state:
>>> transaction.commit()
Traceback (most recent call last):
transaction.interfaces.DoomedTransaction: transaction doomed, cannot commit
>>> transaction.abort()
We have to repair the fuchsturm object by hand as it was not part of the
transaction:
>>> fuchsturm.__parent__ = fuchsturm.__name__ = None
>>> from gocept.reference.interfaces import IReferenceSource
>>> IReferenceSource(fuchsturm).verify_integrity()
False
>>> IReferenceTarget(root['halle']).is_referenced()
False
>>> fuchsturm.city = root['halle']
>>> IReferenceSource(fuchsturm).verify_integrity()
True
>>> IReferenceTarget(root['halle']).is_referenced()
False
>>> root['fuchsturm'] = fuchsturm
>>> IReferenceTarget(root['halle']).is_referenced()
True
>>> fuchsturm = root['fuchsturm']
>>> del root['fuchsturm']
>>> fuchsturm.city is root['halle']
True
>>> del root['halle']
>>> 'halle' in root
False
Hierarchical structures
-----------------------
Trying to delete objects that contain referenced objects with ensured
integrity is also forbidden:
>>> import zope.container.sample
>>> root['folder'] = zope.container.sample.SampleContainer()
>>> root['folder']['frankfurt'] = City()
>>> messeturm = Monument()
>>> messeturm.city = root['folder']['frankfurt']
>>> root['messeturm'] = messeturm
Deleting the `folder` will fail now, because a subobject is being referenced.
The reference target API (IReferenceTarget) allows us to inspect it
beforehand:
>>> from gocept.reference.interfaces import IReferenceTarget
>>> folder_target = IReferenceTarget(root['folder'])
>>> folder_target.is_referenced()
True
>>> folder_target.is_referenced(recursive=False)
False
>>> del root['folder']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move
<zope.container.sample.SampleContainer object at 0x...>.
The (sub-)object <gocept.reference.testing.City object at 0x...> is still
being referenced.
Upgrading from unconstrained to constrained references
------------------------------------------------------
XXX
Downgrading from integrity ensured references to unensured
----------------------------------------------------------
XXX
=====================
Reference collections
=====================
To have an attribute of an object reference multiple other objects using a
collection you can use a ReferenceCollection property.
A collection behaves like a set and manages references while objects are added
or removed from the set:
>>> import zope.component.hooks
>>> root = getRootFolder()
>>> zope.component.hooks.setSite(root)
We need a class defining a ReferenceCollection. (Importing the class
from the test module is necessary to persist instances of the class):
>>> from zope.container.contained import Contained
>>> import gocept.reference
>>> import zope.interface
>>> from zope.annotation.interfaces import IAttributeAnnotatable
>>> from gocept.reference.testing import City
Initially, the collection isn't set and accessing it causes an
AttributeError:
>>> halle = City()
>>> halle.cultural_institutions
Traceback (most recent call last):
AttributeError: cultural_institutions
So we define some cultural institutions:
>>> class CulturalInstitution(Contained):
... title = None
>>> from gocept.reference.testing import CulturalInstitution
>>> root['theatre'] = CulturalInstitution()
>>> root['cinema'] = CulturalInstitution()
>>> root['park'] = CulturalInstitution()
>>> import transaction
>>> transaction.commit()
Trying to set an individual value instead of a collection, raises a
TypeError:
>>> halle.cultural_institutions = root['park']
Traceback (most recent call last):
TypeError: <gocept.reference.testing.CulturalInstitution object at 0x...> can't be assigned as a reference collection: only sets are allowed.
Managing whole sets
===================
Assigning a set works:
>>> halle.cultural_institutions = set([root['park'], root['cinema']])
>>> len(halle.cultural_institutions)
2
>>> list(halle.cultural_institutions)
[<gocept.reference.testing.CulturalInstitution object at 0x...>,
<gocept.reference.testing.CulturalInstitution object at 0x...>]
As `halle` isn't located yet, the integrity ensurance doesn't notice
referenced objects being deleted:
>>> del root['cinema']
The result is a broken reference:
>>> list(halle.cultural_institutions)
Traceback (most recent call last):
gocept.reference.interfaces.LookupError: Reference target '/cinema' no longer exists.
Also, we can not locate `halle` right now, as long as the reference is broken:
>>> root['halle'] = halle
Traceback (most recent call last):
gocept.reference.interfaces.LookupError: Reference target '/cinema' no longer exists.
The transaction was doomed, so we abort:
>>> transaction.abort()
Unfortunately, the `abort` doesn't roll-back the attributes of Halle because it
wasn't part of the transaction yet (as it couldn't be added to the database).
We need to clean up manually, otherwise the next assignment won't raise any
events:
>>> halle.__name__ = None
>>> halle.__parent__ = None
The cinema is back now, and Halle is in an operational state again:
>>> list(halle.cultural_institutions)
[<gocept.reference.testing.CulturalInstitution object at 0x...>,
<gocept.reference.testing.CulturalInstitution object at 0x...>]
Now we can add it to the database:
>>> root['halle'] = halle
>>> transaction.commit()
And deleting a referenced object will cause an error:
>>> del root['cinema']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> transaction.abort()
When we remove the referencing collection, the target can be deleted again:
>>> halle.cultural_institutions = None
>>> del root['cinema']
Managing individual items of sets
=================================
Note: We did not implement the set API 100%. We'll add methods as we need
them.
In addition to changing sets by assigning complete new sets, we can modify the
sets with individual items just as the normal `set` API allows us to do.
We'll start out with an empty set:
>>> root['jena'] = City()
>>> root['jena'].cultural_institutions = set()
Our reference engine turns this set into a different object which manages the
references:
>>> ci = root['jena'].cultural_institutions
>>> ci
InstrumentedSet([])
We can add new references, by adding objects to this set and the referenced
integrity is ensured:
>>> ci.add(root['park'])
>>> transaction.commit()
>>> del root['park']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> transaction.abort()
Removing and discarding works:
>>> ci.remove(root['park'])
>>> del root['park']
>>> root['park'] = CulturalInstitution()
>>> ci.add(root['park'])
>>> transaction.commit()
>>> del root['park']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> transaction.abort()
>>> ci.discard(root['park'])
>>> del root['park']
>>> ci.discard(root['halle'])
Clearing works:
>>> ci.add(root['theatre'])
>>> transaction.commit()
>>> del root['theatre']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> transaction.abort()
>>> ci.clear()
>>> len(ci)
0
>>> del root['theatre']
>>> root['cinema'] = CulturalInstitution()
>>> root['cinema'].title = 'Cinema'
>>> ci.add(root['cinema'])
>>> transaction.commit()
>>> del root['cinema']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> transaction.abort()
>>> ci.pop().title
'Cinema'
>>> del root['cinema']
Updating works:
>>> root['cinema'] = CulturalInstitution()
>>> root['theatre'] = CulturalInstitution()
>>> ci.update([root['cinema'], root['theatre']])
>>> len(ci)
2
>>> del root['cinema']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
>>> del root['theatre']
Traceback (most recent call last):
gocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.
=============================
Verifying reference existence
=============================
It is not so easy to verify a class implements an attribute as a
reference as their usage is transparent.
References
==========
Let's build an example interface and class using a reference:
>>> import zope.interface
>>> import gocept.reference
>>> import zope.annotation.interfaces
>>> class IAddress(zope.interface.Interface):
... city = zope.interface.Attribute("City the address belonges to.")
>>> @zope.interface.implementer(
... zope.annotation.interfaces.IAttributeAnnotatable, IAddress)
... class Address(object):
... city = gocept.reference.Reference()
verifyClass does not check for attributes:
>>> import zope.interface.verify
>>> zope.interface.verify.verifyClass(IAddress, Address)
True
verifyObject tells that the object does not completly fulfill the
interface:
>>> zope.interface.verify.verifyObject(IAddress, Address())
Traceback (most recent call last):
zope.interface.exceptions.BrokenImplementation: The object <...Address object at 0x...> has failed to implement interface builtins.IAddress: The builtins.IAddress.city attribute was not provided.
Setting a value on the reference attribute does not help because after
that it ist not possible to check if there is a reference as the
reference is transparent. Even worse, a class which does not define
the required attribute and an instance thereof with the attribute set,
lets the test pass without defining the reference at all:
>>> @zope.interface.implementer(IAddress)
... class AddressWithoutReference(object):
... pass
>>> address_without_ref = AddressWithoutReference()
>>> address_without_ref.city = None
>>> zope.interface.verify.verifyObject(IAddress, address_without_ref)
True
So we need a special verifyObject function which does a check on the
class if there is a missing attribute:
>>> import gocept.reference.verify
>>> gocept.reference.verify.verifyObject(IAddress, Address())
True
This function is not fully fool proof because it also works with the
instance which has the attribute set. The reason for this behavior is
that the interface does not tell that the attribute must be
implemented as a reference:
>>> gocept.reference.verify.verifyObject(IAddress, address_without_ref)
True
But if the attribute which does not exist on the instance does not
have a reference descriptior on the class the gocept.reference's
verifyObject can detect this:
>>> @zope.interface.implementer(IAddress)
... class StrangeAddress(object):
... @property
... def city(self):
... raise AttributeError
>>> strange_address = StrangeAddress()
>>> gocept.reference.verify.verifyObject(IAddress, strange_address)
Traceback (most recent call last):
zope.interface.exceptions.BrokenImplementation: An object has failed to implement interface builtins.IAddress: The 'city' attribute was not provided.
Like ``zope.interface.verify.verifyObject`` detects, too:
>>> zope.interface.verify.verifyObject(IAddress, strange_address)
Traceback (most recent call last):
zope.interface.exceptions.BrokenImplementation: The object <...StrangeAddress object at 0x...> has failed to implement interface builtins.IAddress: The builtins.IAddress.city attribute was not provided.
Reference collections
=====================
Reference collections suffer the same problem when checked with
zope.inferface.verify.verfyObject:
>>> class ICity(zope.interface.Interface):
... cultural_institutions = zope.interface.Attribute(
... "Cultural institutions the city has.")
>>> @zope.interface.implementer(
... zope.annotation.interfaces.IAttributeAnnotatable, ICity)
... class City(object):
... cultural_institutions = gocept.reference.ReferenceCollection()
>>> zope.interface.verify.verifyObject(ICity, City())
Traceback (most recent call last):
zope.interface.exceptions.BrokenImplementation: The object <...City object at 0x...> has failed to implement interface builtins.ICity: The builtins.ICity.cultural_institutions attribute was not provided.
But the special variant in gocept.reference works for collections, too:
>>> gocept.reference.verify.verifyObject(ICity, City())
True
=================
zope.schema field
=================
To comply with ``zope.schema``, ``gocept.reference`` has an own `set` field
which has the internally used `InstrumentedSet` class as `type`.
For demonstration purposes we create an interface which uses both
``gocept.reference.field.Set`` and ``zope.schema.Set``:
>>> import gocept.reference
>>> import gocept.reference.field
>>> import zope.annotation.interfaces
>>> import zope.interface
>>> import zope.schema
>>> import zope.schema.vocabulary
>>> dumb_vocab = zope.schema.vocabulary.SimpleVocabulary.fromItems(())
>>> class ICollector(zope.interface.Interface):
... gr_items = gocept.reference.field.Set(
... title=u'collected items using gocept.reference.field',
... value_type=zope.schema.Choice(title=u'items', vocabulary=dumb_vocab)
... )
... zs_items = zope.schema.Set(
... title=u'collected items using zope.schema',
... value_type=zope.schema.Choice(title=u'items', vocabulary=dumb_vocab)
... )
>>> @zope.interface.implementer(
... ICollector, zope.annotation.interfaces.IAttributeAnnotatable)
... class Collector(object):
... gr_items = gocept.reference.ReferenceCollection()
... zs_items = gocept.reference.ReferenceCollection()
>>> collector = Collector()
>>> collector.gr_items = set()
>>> collector.gr_items
InstrumentedSet([])
>>> collector.zs_items = set()
>>> collector.zs_items
InstrumentedSet([])
``gocept.reference.field.Set`` validates both ``set`` and
``InstrumentedSet`` and correctly, but raises an exception if
something else is validated:
>>> ICollector['gr_items'].bind(collector).validate(collector.gr_items) is None
True
>>> ICollector['gr_items'].bind(collector).validate(set([])) is None
True
>>> ICollector['gr_items'].bind(collector).validate([])
Traceback (most recent call last):
zope.schema._bootstrapinterfaces.WrongType: ([], (<class 'set'>, <class 'gocept.reference.collection.InstrumentedSet'>), None)
While ``zope.schema.Set`` fails at ``InstrumentedSet`` as expected:
>>> ICollector['zs_items'].bind(collector).validate(collector.zs_items)
Traceback (most recent call last):
zope.schema._bootstrapinterfaces.WrongType: (InstrumentedSet([]), <class 'set'>, 'zs_items')
>>> ICollector['zs_items'].bind(collector).validate(set([])) is None
True
>>> ICollector['zs_items'].bind(collector).validate([])
Traceback (most recent call last):
zope.schema._bootstrapinterfaces.WrongType: ([], <class 'set'>, 'zs_items')
=======
Changes
=======
1.0 (2023-07-20)
================
- Drop support for Python 2.7.
- Add support for Python 3.7, 3.8, 3.9, 3.10, 3.11.
- Fix deprecation warnings.
0.11 (2020-09-10)
=================
- Add the possibility to commit savepoints and output progress for Fixer.
0.10 (2020-04-01)
=================
- Support Python 3.8.
- Use tox as only test setup.
- Switch dependency from ``ZODB3`` to ``ZODB``.
- Migrate to Github.
0.9.4 (2017-05-15)
==================
- Version 0.9.3 did not include all files. Fixing this by adding a
MANIFEST.in.
0.9.3 (2017-05-14)
==================
- Use `pytest` as test runner.
0.9.2 (2015-08-05)
==================
- Move repos to https://bitbucket.org/gocept/gocept.reference
0.9.1 (2011-02-02)
==================
- Bug fixed: reference descriptors could not find out their attribute names
when read from the class.
- Bug fixed: the algorithm for digging up the attribute name of a reference
descriptor on a class would not handle inherited references.
0.9.0 (2010-09-18)
==================
- Depending on ``zope.generations`` instead of ``zope.app.generations``.
0.8.0 (2010-08-20)
==================
- Updated tests to work with `zope.schema` 3.6.
- Removed unused parameter of ``InstrumentedSet.__init__``.
- Avoid ``sets`` module as it got deprecated in Python 2.6.
0.7.2 (2009-06-30)
==================
- Fixed generation added in previous version.
0.7.1 (2009-04-28)
==================
- Fixed reference counting for reference collections by keeping a usage
counter for InstrumentedSets.
- Added a tool that rebuilds all reference counts. Added a database generation
that uses this tool to set up the new usage counts for InstrumentedSets.
0.7.0 (2009-04-06)
==================
- Require newer ``zope.app.generations`` version to get rid of
dependency on ``zope.app.zopeappgenerations``.
0.6.2 (2009-03-27)
==================
- Validation of ``gocept.reference.field.Set`` now allows both
``InstrumentedSet`` and ``set`` in field validation, as both
variants occur.
0.6.1 (2009-03-27)
==================
- ``zope.app.form`` breaks encapsulation of the fields by using the
``_type`` attribute to convert form values to field values. Using
``InstrumentedSet`` as ``_type`` was a bad idea, as only the
reference collection knows how to instantiate an
``InstrumentedSet``. Now the trick is done on validation where the
``_type`` gets set to ``InstrumentedSet`` temporarily.
0.6 (2009-03-26)
================
- Take advantage of the simpler zope package dependencies achieved at the Grok
cave sprint in January 2009.
- Added zope.schema field ``gocept.reference.field.Set`` which has the
internally used InstrumentedSet as field type, so validation does
not fail.
- gocept.reference 0.5.2 had a consistency bug: Causing a TypeError by
trying to assign a non-collection to a ReferenceCollection attribute
would break integrity enforcement for that attribute while keeping
its previously assigned value.
0.5.2 (2008-10-16)
==================
- Fixed: When upgrading gocept.reference to version 0.5.1, a
duplication error was raised.
0.5.1 (2008-10-10)
==================
- Made sure that the reference manager is installed using
zope.app.generations before other packages depending on
gocept.reference.
0.5 (2008-09-11)
================
- Added specialized variant of zope.interface.verify.verifyObject
which can handle references and reference collections correctly.
0.4 (2008-09-08)
================
- Moved InstrumentedSet to use BTree data structures for better performance.
- Added `update` method to InstrumentedSet.
- Updated documentation.
0.3 (2008-04-22)
================
- Added a `set` implementation for referencing collections of objects.
0.2 (2007-12-21)
================
- Extended the API for `IReferenceTarget.is_referenced` to allow specifying
whether to query for references recursively or only on a specific object.
By default the query is recursive.
- Fixed bug in the event handler for enforcing ensured constraints: referenced
objects could be deleted if they were deleted together with a parent
location.
0.1 (2007-12-20)
================
Initial release.
Raw data
{
"_id": null,
"home_page": "https://github.com/gocept/gocept.reference",
"name": "gocept.reference",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": "",
"keywords": "zodb zope3 intrinsic reference",
"author": "gocept gmbh & co. kg",
"author_email": "mail@gocept.com",
"download_url": "https://files.pythonhosted.org/packages/e3/d8/2cd22d7bdd33d4b150755a19c54bdcfd17124c8c8b44b35de5f2fc210b00/gocept.reference-1.0.tar.gz",
"platform": null,
"description": "Copyright (c) 2007-2022 gocept gmbh & co. kg and contributors.\n\nAll Rights Reserved.\n\nThis software is subject to the provisions of the Zope Public License,\nVersion 2.1 (ZPL). A copy of the ZPL should accompany this distribution.\nTHIS SOFTWARE IS PROVIDED \"AS IS\" AND ANY AND ALL EXPRESS OR IMPLIED\nWARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS\nFOR A PARTICULAR PURPOSE.\n\n\n============\nIntroduction\n============\n\nThis package provides a reference implementation.\n\nThe specific properties of this implementation are:\n\n- intended to be used for intrinsic references\n\n- provides integrity enforcement\n\n- modelled partially after relational `foreign keys`\n\n.. contents::\n\n\nMotivation\n==========\n\nWhen developing an application we often find the need to reference objects\nthat are stored as application data. Examples of such objects include\ncentrally managed 'master data'.\n\nThe reference to those objects is typically intrinsic to the application we\ndevelop so they should behave like normal Python object references while being\nunder the control of our application.\n\nWithin the world of Zope and ZODB there are different ways to achieve this. The\nvarious approaches have different semantics and side effects. Our goal is to\nunify the way of intrinsically referencing objects and to provide the ability to\nswitch between different semantics as needed without rewriting application code\nand without the need to migrate persistent data structures (at least from the\napplication's point of view).\n\n\nModel comparison\n================\n\nOur goal was to determine the advantages and disadvantages of the different\nexisting approaches. We included three general approaches from the world of\nPython/Zope/ZODB as well as the standard relational approach to normalisation\ntables.\n\nWe used four criteria to describe each solution:\n\nReference data\n What data is stored to describe the reference?\n\nReference semantics\n What meaning does the reference have? How can its meaning change?\n\nIntegrity\n What might happen to the application if data that is involved in the\n reference changes or is deleted?\n\nSet/Lookup\n What does the application developer have to do to set a reference or\n look up a referenced object?\n\n\n====================== ========================================= =========================================== ======================================== ====================================================\nProperty Python references Weak references Key reference Relational DBs\n====================== ========================================= =========================================== ======================================== ====================================================\nReference data OID OID application-specific key application-specific (primary key + table name)\n\nReference semantics Refers to a specific Refers to a specific Refers to an object which Refers to an object (row) that is associated\n Python object Python object is associated with the saved key with the primary key at the time of the lookup.\n at the time of the lookup.\n\nIntegrity The reference stays valid, however, The reference might have become stale The reference might have become Dependening on the use of `foreign keys`\n the target object might have lost its and leave the referencing object in an stale. and the databases implementation of constraints.\n meaning for the application. invalid state. Can usually be forced to stay valid.\n\nSet/Lookup Normal Python attribute access. Use WeakRef wrapper to store and Depends on the implementation. Explicitly store the primary key.\n __call__ to lookup. Might use properties Might use properties for convenience. Use JOIN to look up.\n for convenience.\n====================== ========================================= =========================================== ======================================== ====================================================\n\n\nObservations\n============\n\n- Relational: every object (row) has a canonical place that defines a primary\n key.\n\n The ZODB (like a filesystem) can have multiple hard links to an object.\n Objects are deleted when the last hard link to an object is removed. This\n makes it impossible to use hard links for referencing an object because\n object deletion will not be noticed and the objects will continue to live.\n The ZODB itself does not have a notion of a canonical place where an object\n is defined.\n\n- Relational: When referencing an object we can enforce integrity by declaring\n a foreign key. This is orthogonal to the data stored.\n\n- Relational: As an application-level key is used for identifying the target\n of a reference, the application can choose to delete a row and re-add a row\n with the same primary key later. If the integrity is enforced this requires\n support on the database level to temporarily ignore broken foreign keys.\n\n- Normal Python references embed themselves naturally in the application.\n Properties allow hiding the implementation of looking up and storing\n references.\n\n\nConclusions & Requirements for the reference implementation\n===========================================================\n\n- Allow configuration of `foreign key` constraints (none, always, at the end\n of the transaction). This configuration must be changable at any time with\n an automatic migration path provided.\n\n- Use application level keys to refer to an object.\n\n- Use a canonical location and a primary key to store objects and to determine\n whether an object was deleted.\n\n- Distinguish between two use cases when modifying an object's key:\n\n 1. The application references the right object but has the wrong key (as the\n key itself might have meaning for the application). In this case the\n object must be updated to receive the new, correct key and the references\n must be updated to refer to this new key.\n\n 2. The application references the wrong object with the right key. In this\n case the object referenced by the key must be replaced with a different\n object.\n\n\nImplementation notes\n====================\n\n- Canonical location is determined by location/containment. The primary key for\n a reference is the referenced object's location.\n\n- Constraints are enforced by monitoring containment events.\n\n- The different ways of updating/changing a key's meaning are supported by an\n indirection that enumerates all keys and stores a `reference id` on the\n referencing object instead of the location. The two use cases for changing\n the meaning are implemented by:\n\n 1. associating a new path with an existing reference id\n\n 2. associating a new reference id with an existing path\n\n\n===================\nReferencing objects\n===================\n\nSimple references\n=================\n\nFor working with references you have to have a located site set:\n\n>>> import zope.component.hooks\n>>> root = getRootFolder()\n>>> zope.component.hooks.setSite(root)\n\nFor demonstration purposes we define two classes, one for referenced objects,\nthe other defining the reference. Classes using references have to implement\nIAttributeAnnotatable as references are stored as annotations:\n\n>>> from zope.container.contained import Contained\n>>> import gocept.reference\n>>> import zope.interface\n>>> from zope.annotation.interfaces import IAttributeAnnotatable\n\n>>> @zope.interface.implementer(IAttributeAnnotatable)\n... class Address(Contained):\n... city = gocept.reference.Reference()\n\n>>> class City(Contained):\n... pass\n\nAs instances of classes defined in a doctest cannot be persisted, we import\nimplementations of the classes from a real Python module:\n\n>>> from gocept.reference.testing import Address, City\n\nThe referenced objects must be stored in the ZODB and must be located:\n\n>>> root['dessau'] = City()\n>>> root['halle'] = City()\n>>> root['jena'] = City()\n\nIn order to reference an object, the object only needs to be assigned to the\nattribute implemented as a reference descriptor:\n\n>>> theuni = Address()\n>>> theuni.city = root['dessau']\n>>> theuni.city\n<gocept.reference.testing.City object at 0x...>\n\nIt is also possible to assign `None` to let the reference point to no\nobject:\n\n>>> theuni.city = None\n>>> print(theuni.city)\nNone\n\nValues can be deleted, the descriptor raises an AttributeError then:\n\n>>> del theuni.city\n>>> theuni.city\nTraceback (most recent call last):\nAttributeError: city\n\nOnly contained objects can be assigned to a reference that has\nintegrity ensurance enabled:\n\n>>> theuni.city = 12\nTraceback (most recent call last):\nTypeError: ...\n\n\nIntegrity-ensured references\n============================\n\n>>> @zope.interface.implementer(IAttributeAnnotatable)\n... class Monument(Contained):\n... city = gocept.reference.Reference(ensure_integrity=True)\n>>> from gocept.reference.testing import Monument\n\nLocated source\n--------------\n\nReferential integrity can be ensured if the source of the reference is\nlocated:\n\n>>> root['fuchsturm'] = Monument()\n>>> root['fuchsturm'].city = root['dessau']\n>>> root['fuchsturm'].city is root['dessau']\nTrue\n\n>>> import transaction\n>>> transaction.commit()\n\n>>> del root['dessau']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move\n <gocept.reference.testing.City object at 0x...>.\n The (sub-)object <gocept.reference.testing.City object at 0x...> is\n still being referenced.\n\n>>> transaction.commit()\nTraceback (most recent call last):\ntransaction.interfaces.DoomedTransaction: transaction doomed, cannot commit\n\n>>> transaction.abort()\n>>> 'dessau' in root\nTrue\n\nTo check whether an object is referenced, it can be adapted to\nIReferenceTarget:\n\n>>> from gocept.reference.interfaces import IReferenceTarget\n>>> IReferenceTarget(root['dessau']).is_referenced()\nTrue\n\n>>> root['fuchsturm'].city = None\n>>> IReferenceTarget(root['dessau']).is_referenced()\nFalse\n\n>>> del root['dessau']\n>>> 'dessau' in root\nFalse\n\nXXX References will also be correctly cancelled when the attribute or the\nsource is deleted.\n\n>>> del root['fuchsturm']\n\nNon-located source\n------------------\n\nIf the source of a reference is not located, we can do anything we want with\nreferences, including breaking them:\n\n>>> fuchsturm = Monument()\n>>> fuchsturm.city = root['jena']\n>>> fuchsturm.city is root['jena']\nTrue\n\n>>> del fuchsturm.city\n>>> fuchsturm.city\nTraceback (most recent call last):\nAttributeError: city\n\n>>> fuchsturm.city = root['jena']\n>>> fuchsturm.city is root['jena']\nTrue\n\n>>> del root['jena']\n>>> fuchsturm.city\nTraceback (most recent call last):\ngocept.reference.interfaces.LookupError: Reference target '/jena' no longer exists.\n\n\nChanging the location state of the source\n-----------------------------------------\n\nWe cannot put an object with a broken reference back into containment since\nreferential integrity is not given:\n\n>>> transaction.commit()\n\n>>> root['fuchsturm'] = fuchsturm\nTraceback (most recent call last):\ngocept.reference.interfaces.LookupError: Reference target '/jena' no longer exists.\n\nThe transaction was doomed, let's recover the last working state:\n\n>>> transaction.commit()\nTraceback (most recent call last):\ntransaction.interfaces.DoomedTransaction: transaction doomed, cannot commit\n\n>>> transaction.abort()\n\nWe have to repair the fuchsturm object by hand as it was not part of the\ntransaction:\n\n>>> fuchsturm.__parent__ = fuchsturm.__name__ = None\n\n>>> from gocept.reference.interfaces import IReferenceSource\n>>> IReferenceSource(fuchsturm).verify_integrity()\nFalse\n\n>>> IReferenceTarget(root['halle']).is_referenced()\nFalse\n>>> fuchsturm.city = root['halle']\n>>> IReferenceSource(fuchsturm).verify_integrity()\nTrue\n>>> IReferenceTarget(root['halle']).is_referenced()\nFalse\n\n>>> root['fuchsturm'] = fuchsturm\n>>> IReferenceTarget(root['halle']).is_referenced()\nTrue\n\n>>> fuchsturm = root['fuchsturm']\n>>> del root['fuchsturm']\n>>> fuchsturm.city is root['halle']\nTrue\n\n>>> del root['halle']\n>>> 'halle' in root\nFalse\n\nHierarchical structures\n-----------------------\n\nTrying to delete objects that contain referenced objects with ensured\nintegrity is also forbidden:\n\n>>> import zope.container.sample\n>>> root['folder'] = zope.container.sample.SampleContainer()\n>>> root['folder']['frankfurt'] = City()\n>>> messeturm = Monument()\n>>> messeturm.city = root['folder']['frankfurt']\n>>> root['messeturm'] = messeturm\n\nDeleting the `folder` will fail now, because a subobject is being referenced.\nThe reference target API (IReferenceTarget) allows us to inspect it\nbeforehand:\n\n>>> from gocept.reference.interfaces import IReferenceTarget\n>>> folder_target = IReferenceTarget(root['folder'])\n>>> folder_target.is_referenced()\nTrue\n>>> folder_target.is_referenced(recursive=False)\nFalse\n\n\n>>> del root['folder']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move\n <zope.container.sample.SampleContainer object at 0x...>.\n The (sub-)object <gocept.reference.testing.City object at 0x...> is still\n being referenced.\n\n\nUpgrading from unconstrained to constrained references\n------------------------------------------------------\n\nXXX\n\nDowngrading from integrity ensured references to unensured\n----------------------------------------------------------\n\nXXX\n\n\n=====================\nReference collections\n=====================\n\nTo have an attribute of an object reference multiple other objects using a\ncollection you can use a ReferenceCollection property.\n\nA collection behaves like a set and manages references while objects are added\nor removed from the set:\n\n>>> import zope.component.hooks\n>>> root = getRootFolder()\n>>> zope.component.hooks.setSite(root)\n\nWe need a class defining a ReferenceCollection. (Importing the class\nfrom the test module is necessary to persist instances of the class):\n\n>>> from zope.container.contained import Contained\n>>> import gocept.reference\n>>> import zope.interface\n>>> from zope.annotation.interfaces import IAttributeAnnotatable\n>>> from gocept.reference.testing import City\n\nInitially, the collection isn't set and accessing it causes an\nAttributeError:\n\n>>> halle = City()\n>>> halle.cultural_institutions\nTraceback (most recent call last):\nAttributeError: cultural_institutions\n\nSo we define some cultural institutions:\n\n>>> class CulturalInstitution(Contained):\n... title = None\n>>> from gocept.reference.testing import CulturalInstitution\n\n>>> root['theatre'] = CulturalInstitution()\n>>> root['cinema'] = CulturalInstitution()\n>>> root['park'] = CulturalInstitution()\n>>> import transaction\n>>> transaction.commit()\n\nTrying to set an individual value instead of a collection, raises a\nTypeError:\n\n>>> halle.cultural_institutions = root['park']\nTraceback (most recent call last):\nTypeError: <gocept.reference.testing.CulturalInstitution object at 0x...> can't be assigned as a reference collection: only sets are allowed.\n\n\nManaging whole sets\n===================\n\nAssigning a set works:\n\n>>> halle.cultural_institutions = set([root['park'], root['cinema']])\n>>> len(halle.cultural_institutions)\n2\n>>> list(halle.cultural_institutions)\n[<gocept.reference.testing.CulturalInstitution object at 0x...>,\n <gocept.reference.testing.CulturalInstitution object at 0x...>]\n\nAs `halle` isn't located yet, the integrity ensurance doesn't notice\nreferenced objects being deleted:\n\n>>> del root['cinema']\n\nThe result is a broken reference:\n\n>>> list(halle.cultural_institutions)\nTraceback (most recent call last):\ngocept.reference.interfaces.LookupError: Reference target '/cinema' no longer exists.\n\nAlso, we can not locate `halle` right now, as long as the reference is broken:\n\n>>> root['halle'] = halle\nTraceback (most recent call last):\ngocept.reference.interfaces.LookupError: Reference target '/cinema' no longer exists.\n\nThe transaction was doomed, so we abort:\n\n>>> transaction.abort()\n\nUnfortunately, the `abort` doesn't roll-back the attributes of Halle because it\nwasn't part of the transaction yet (as it couldn't be added to the database).\nWe need to clean up manually, otherwise the next assignment won't raise any\nevents:\n\n>>> halle.__name__ = None\n>>> halle.__parent__ = None\n\nThe cinema is back now, and Halle is in an operational state again:\n\n>>> list(halle.cultural_institutions)\n[<gocept.reference.testing.CulturalInstitution object at 0x...>,\n <gocept.reference.testing.CulturalInstitution object at 0x...>]\n\nNow we can add it to the database:\n\n>>> root['halle'] = halle\n>>> transaction.commit()\n\nAnd deleting a referenced object will cause an error:\n\n>>> del root['cinema']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> transaction.abort()\n\nWhen we remove the referencing collection, the target can be deleted again:\n\n>>> halle.cultural_institutions = None\n>>> del root['cinema']\n\nManaging individual items of sets\n=================================\n\nNote: We did not implement the set API 100%. We'll add methods as we need\nthem.\n\nIn addition to changing sets by assigning complete new sets, we can modify the\nsets with individual items just as the normal `set` API allows us to do.\n\nWe'll start out with an empty set:\n\n>>> root['jena'] = City()\n>>> root['jena'].cultural_institutions = set()\n\nOur reference engine turns this set into a different object which manages the\nreferences:\n\n>>> ci = root['jena'].cultural_institutions\n>>> ci\nInstrumentedSet([])\n\nWe can add new references, by adding objects to this set and the referenced\nintegrity is ensured:\n\n>>> ci.add(root['park'])\n>>> transaction.commit()\n>>> del root['park']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> transaction.abort()\n\nRemoving and discarding works:\n\n>>> ci.remove(root['park'])\n>>> del root['park']\n>>> root['park'] = CulturalInstitution()\n>>> ci.add(root['park'])\n>>> transaction.commit()\n>>> del root['park']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> transaction.abort()\n>>> ci.discard(root['park'])\n>>> del root['park']\n>>> ci.discard(root['halle'])\n\nClearing works:\n\n>>> ci.add(root['theatre'])\n>>> transaction.commit()\n>>> del root['theatre']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> transaction.abort()\n>>> ci.clear()\n>>> len(ci)\n0\n>>> del root['theatre']\n\n>>> root['cinema'] = CulturalInstitution()\n>>> root['cinema'].title = 'Cinema'\n>>> ci.add(root['cinema'])\n>>> transaction.commit()\n>>> del root['cinema']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> transaction.abort()\n>>> ci.pop().title\n'Cinema'\n>>> del root['cinema']\n\nUpdating works:\n\n>>> root['cinema'] = CulturalInstitution()\n>>> root['theatre'] = CulturalInstitution()\n>>> ci.update([root['cinema'], root['theatre']])\n>>> len(ci)\n2\n>>> del root['cinema']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n>>> del root['theatre']\nTraceback (most recent call last):\ngocept.reference.interfaces.IntegrityError: Can't delete or move <gocept.reference.testing.CulturalInstitution object at 0x...>. The (sub-)object <gocept.reference.testing.CulturalInstitution object at 0x...> is still being referenced.\n\n\n=============================\nVerifying reference existence\n=============================\n\nIt is not so easy to verify a class implements an attribute as a\nreference as their usage is transparent.\n\nReferences\n==========\n\nLet's build an example interface and class using a reference:\n\n>>> import zope.interface\n>>> import gocept.reference\n>>> import zope.annotation.interfaces\n>>> class IAddress(zope.interface.Interface):\n... city = zope.interface.Attribute(\"City the address belonges to.\")\n>>> @zope.interface.implementer(\n... \tzope.annotation.interfaces.IAttributeAnnotatable, IAddress)\n... class Address(object):\n... city = gocept.reference.Reference()\n\nverifyClass does not check for attributes:\n\n>>> import zope.interface.verify\n>>> zope.interface.verify.verifyClass(IAddress, Address)\nTrue\n\nverifyObject tells that the object does not completly fulfill the\ninterface:\n\n>>> zope.interface.verify.verifyObject(IAddress, Address())\nTraceback (most recent call last):\nzope.interface.exceptions.BrokenImplementation: The object <...Address object at 0x...> has failed to implement interface builtins.IAddress: The builtins.IAddress.city attribute was not provided.\n\nSetting a value on the reference attribute does not help because after\nthat it ist not possible to check if there is a reference as the\nreference is transparent. Even worse, a class which does not define\nthe required attribute and an instance thereof with the attribute set,\nlets the test pass without defining the reference at all:\n\n>>> @zope.interface.implementer(IAddress)\n... class AddressWithoutReference(object):\n... \tpass\n>>> address_without_ref = AddressWithoutReference()\n>>> address_without_ref.city = None\n>>> zope.interface.verify.verifyObject(IAddress, address_without_ref)\nTrue\n\nSo we need a special verifyObject function which does a check on the\nclass if there is a missing attribute:\n\n>>> import gocept.reference.verify\n>>> gocept.reference.verify.verifyObject(IAddress, Address())\nTrue\n\nThis function is not fully fool proof because it also works with the\ninstance which has the attribute set. The reason for this behavior is\nthat the interface does not tell that the attribute must be\nimplemented as a reference:\n\n>>> gocept.reference.verify.verifyObject(IAddress, address_without_ref)\nTrue\n\nBut if the attribute which does not exist on the instance does not\nhave a reference descriptior on the class the gocept.reference's\nverifyObject can detect this:\n\n>>> @zope.interface.implementer(IAddress)\n... class StrangeAddress(object):\n... @property\n... def city(self):\n... raise AttributeError\n>>> strange_address = StrangeAddress()\n>>> gocept.reference.verify.verifyObject(IAddress, strange_address)\nTraceback (most recent call last):\nzope.interface.exceptions.BrokenImplementation: An object has failed to implement interface builtins.IAddress: The 'city' attribute was not provided.\n\nLike ``zope.interface.verify.verifyObject`` detects, too:\n\n>>> zope.interface.verify.verifyObject(IAddress, strange_address)\nTraceback (most recent call last):\nzope.interface.exceptions.BrokenImplementation: The object <...StrangeAddress object at 0x...> has failed to implement interface builtins.IAddress: The builtins.IAddress.city attribute was not provided.\n\nReference collections\n=====================\n\nReference collections suffer the same problem when checked with\nzope.inferface.verify.verfyObject:\n\n>>> class ICity(zope.interface.Interface):\n... cultural_institutions = zope.interface.Attribute(\n... \"Cultural institutions the city has.\")\n>>> @zope.interface.implementer(\n... zope.annotation.interfaces.IAttributeAnnotatable, ICity)\n... class City(object):\n... cultural_institutions = gocept.reference.ReferenceCollection()\n\n>>> zope.interface.verify.verifyObject(ICity, City())\nTraceback (most recent call last):\nzope.interface.exceptions.BrokenImplementation: The object <...City object at 0x...> has failed to implement interface builtins.ICity: The builtins.ICity.cultural_institutions attribute was not provided.\n\nBut the special variant in gocept.reference works for collections, too:\n\n>>> gocept.reference.verify.verifyObject(ICity, City())\nTrue\n\n\n=================\nzope.schema field\n=================\n\nTo comply with ``zope.schema``, ``gocept.reference`` has an own `set` field\nwhich has the internally used `InstrumentedSet` class as `type`.\n\nFor demonstration purposes we create an interface which uses both\n``gocept.reference.field.Set`` and ``zope.schema.Set``:\n\n>>> import gocept.reference\n>>> import gocept.reference.field\n>>> import zope.annotation.interfaces\n>>> import zope.interface\n>>> import zope.schema\n>>> import zope.schema.vocabulary\n>>> dumb_vocab = zope.schema.vocabulary.SimpleVocabulary.fromItems(())\n>>> class ICollector(zope.interface.Interface):\n... gr_items = gocept.reference.field.Set(\n... title=u'collected items using gocept.reference.field',\n... value_type=zope.schema.Choice(title=u'items', vocabulary=dumb_vocab)\n... )\n... zs_items = zope.schema.Set(\n... title=u'collected items using zope.schema',\n... value_type=zope.schema.Choice(title=u'items', vocabulary=dumb_vocab)\n... )\n\n>>> @zope.interface.implementer(\n... ICollector, zope.annotation.interfaces.IAttributeAnnotatable)\n... class Collector(object):\n... gr_items = gocept.reference.ReferenceCollection()\n... zs_items = gocept.reference.ReferenceCollection()\n\n>>> collector = Collector()\n>>> collector.gr_items = set()\n>>> collector.gr_items\nInstrumentedSet([])\n>>> collector.zs_items = set()\n>>> collector.zs_items\nInstrumentedSet([])\n\n``gocept.reference.field.Set`` validates both ``set`` and\n``InstrumentedSet`` and correctly, but raises an exception if\nsomething else is validated:\n\n>>> ICollector['gr_items'].bind(collector).validate(collector.gr_items) is None\nTrue\n>>> ICollector['gr_items'].bind(collector).validate(set([])) is None\nTrue\n>>> ICollector['gr_items'].bind(collector).validate([])\nTraceback (most recent call last):\nzope.schema._bootstrapinterfaces.WrongType: ([], (<class 'set'>, <class 'gocept.reference.collection.InstrumentedSet'>), None)\n\nWhile ``zope.schema.Set`` fails at ``InstrumentedSet`` as expected:\n\n>>> ICollector['zs_items'].bind(collector).validate(collector.zs_items)\nTraceback (most recent call last):\nzope.schema._bootstrapinterfaces.WrongType: (InstrumentedSet([]), <class 'set'>, 'zs_items')\n\n>>> ICollector['zs_items'].bind(collector).validate(set([])) is None\nTrue\n>>> ICollector['zs_items'].bind(collector).validate([])\nTraceback (most recent call last):\nzope.schema._bootstrapinterfaces.WrongType: ([], <class 'set'>, 'zs_items')\n\n\n=======\nChanges\n=======\n\n1.0 (2023-07-20)\n================\n\n- Drop support for Python 2.7.\n\n- Add support for Python 3.7, 3.8, 3.9, 3.10, 3.11.\n\n- Fix deprecation warnings.\n\n\n0.11 (2020-09-10)\n=================\n\n- Add the possibility to commit savepoints and output progress for Fixer.\n\n\n0.10 (2020-04-01)\n=================\n\n- Support Python 3.8.\n\n- Use tox as only test setup.\n\n- Switch dependency from ``ZODB3`` to ``ZODB``.\n\n- Migrate to Github.\n\n\n0.9.4 (2017-05-15)\n==================\n\n- Version 0.9.3 did not include all files. Fixing this by adding a\n MANIFEST.in.\n\n\n0.9.3 (2017-05-14)\n==================\n\n- Use `pytest` as test runner.\n\n\n0.9.2 (2015-08-05)\n==================\n\n- Move repos to https://bitbucket.org/gocept/gocept.reference\n\n\n0.9.1 (2011-02-02)\n==================\n\n- Bug fixed: reference descriptors could not find out their attribute names\n when read from the class.\n\n- Bug fixed: the algorithm for digging up the attribute name of a reference\n descriptor on a class would not handle inherited references.\n\n\n0.9.0 (2010-09-18)\n==================\n\n- Depending on ``zope.generations`` instead of ``zope.app.generations``.\n\n\n0.8.0 (2010-08-20)\n==================\n\n- Updated tests to work with `zope.schema` 3.6.\n\n- Removed unused parameter of ``InstrumentedSet.__init__``.\n\n- Avoid ``sets`` module as it got deprecated in Python 2.6.\n\n\n0.7.2 (2009-06-30)\n==================\n\n- Fixed generation added in previous version.\n\n\n0.7.1 (2009-04-28)\n==================\n\n- Fixed reference counting for reference collections by keeping a usage\n counter for InstrumentedSets.\n\n- Added a tool that rebuilds all reference counts. Added a database generation\n that uses this tool to set up the new usage counts for InstrumentedSets.\n\n\n0.7.0 (2009-04-06)\n==================\n\n- Require newer ``zope.app.generations`` version to get rid of\n dependency on ``zope.app.zopeappgenerations``.\n\n\n0.6.2 (2009-03-27)\n==================\n\n- Validation of ``gocept.reference.field.Set`` now allows both\n ``InstrumentedSet`` and ``set`` in field validation, as both\n variants occur.\n\n\n0.6.1 (2009-03-27)\n==================\n\n- ``zope.app.form`` breaks encapsulation of the fields by using the\n ``_type`` attribute to convert form values to field values. Using\n ``InstrumentedSet`` as ``_type`` was a bad idea, as only the\n reference collection knows how to instantiate an\n ``InstrumentedSet``. Now the trick is done on validation where the\n ``_type`` gets set to ``InstrumentedSet`` temporarily.\n\n\n0.6 (2009-03-26)\n================\n\n- Take advantage of the simpler zope package dependencies achieved at the Grok\n cave sprint in January 2009.\n\n- Added zope.schema field ``gocept.reference.field.Set`` which has the\n internally used InstrumentedSet as field type, so validation does\n not fail.\n\n- gocept.reference 0.5.2 had a consistency bug: Causing a TypeError by\n trying to assign a non-collection to a ReferenceCollection attribute\n would break integrity enforcement for that attribute while keeping\n its previously assigned value.\n\n\n0.5.2 (2008-10-16)\n==================\n\n- Fixed: When upgrading gocept.reference to version 0.5.1, a\n duplication error was raised.\n\n\n0.5.1 (2008-10-10)\n==================\n\n- Made sure that the reference manager is installed using\n zope.app.generations before other packages depending on\n gocept.reference.\n\n0.5 (2008-09-11)\n================\n\n- Added specialized variant of zope.interface.verify.verifyObject\n which can handle references and reference collections correctly.\n\n\n0.4 (2008-09-08)\n================\n\n- Moved InstrumentedSet to use BTree data structures for better performance.\n\n- Added `update` method to InstrumentedSet.\n\n- Updated documentation.\n\n\n0.3 (2008-04-22)\n================\n\n- Added a `set` implementation for referencing collections of objects.\n\n0.2 (2007-12-21)\n================\n\n- Extended the API for `IReferenceTarget.is_referenced` to allow specifying\n whether to query for references recursively or only on a specific object.\n By default the query is recursive.\n\n- Fixed bug in the event handler for enforcing ensured constraints: referenced\n objects could be deleted if they were deleted together with a parent\n location.\n\n0.1 (2007-12-20)\n================\n\nInitial release.\n",
"bugtrack_url": null,
"license": "ZPL 2.1",
"summary": "Intrinsic references for Zope/ZODB applications.",
"version": "1.0",
"project_urls": {
"Homepage": "https://github.com/gocept/gocept.reference"
},
"split_keywords": [
"zodb",
"zope3",
"intrinsic",
"reference"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "5bc18c0b2ac4652a3eadf8147826fc879c448759b0df8c838376ceaa843efae2",
"md5": "41b6502aba8428a4c675aeede2d24105",
"sha256": "8f73c8e2019edf7e6d2faefac19546f431381af12f2e325f9926ea44ca9bd1ad"
},
"downloads": -1,
"filename": "gocept.reference-1.0-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "41b6502aba8428a4c675aeede2d24105",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": ">=3.7",
"size": 33468,
"upload_time": "2023-07-20T06:30:52",
"upload_time_iso_8601": "2023-07-20T06:30:52.005427Z",
"url": "https://files.pythonhosted.org/packages/5b/c1/8c0b2ac4652a3eadf8147826fc879c448759b0df8c838376ceaa843efae2/gocept.reference-1.0-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "e3d82cd22d7bdd33d4b150755a19c54bdcfd17124c8c8b44b35de5f2fc210b00",
"md5": "d61ae3e1fd4fe62c2b5b3a88466b8b2e",
"sha256": "1ebaabf88cec59358891f2dd2299b81a0663a7124e72674360e71c79ae7e3f76"
},
"downloads": -1,
"filename": "gocept.reference-1.0.tar.gz",
"has_sig": false,
"md5_digest": "d61ae3e1fd4fe62c2b5b3a88466b8b2e",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 38081,
"upload_time": "2023-07-20T06:30:54",
"upload_time_iso_8601": "2023-07-20T06:30:54.083909Z",
"url": "https://files.pythonhosted.org/packages/e3/d8/2cd22d7bdd33d4b150755a19c54bdcfd17124c8c8b44b35de5f2fc210b00/gocept.reference-1.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-07-20 06:30:54",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "gocept",
"github_project": "gocept.reference",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"tox": true,
"lcname": "gocept.reference"
}
JSON
