merged: opening databases at version other than 1; Schevo 3.1a1dev-r3125 released

0 views
Skip to first unread message

Matthew Scott

unread,
Apr 20, 2007, 1:10:46 PM4/20/07
to Schevo
Schevo 3.1a1dev-r3125 has been pushed to the cheeseshop, with binary
eggs for OSX and Windows.

See http://schevo.org/ticket/46 for status of this ticket. It's still
open, but part of its functionality has been reviewed and merged to
trunk. Here's the changelog:

---

Merge of current state of skip-evolution-46 branch to trunk.
Reviewed by pobrien.

In schevo.test.base:

Convenience method CreatesDatabase.check_entities, for checking
__repr__/__str__/__unicode__ of all entities in an extent.

Additional documentation for attributes on CreatesSchema and
EvolvesSchemata base test classes.

Opening databases directly at a version other than 1:

'schema_version' added to the signature of schevo.database.open, so
that newly-created databases can be given a version number other than
the default of version 1.

'schema_version' also added to signature of Database._sync method in
schevo.database1 and schevo.database2.

Tests for new functionality:

New tests in test_evolve, to test the schevo.test.EvolvesSchemata
class. In the schemata that the new tests use, version 1 has some
initial values for an extent and version 2 has the same list, but with
an additional initial value. However there is an intentional "error"
in version 2, in that the after_evolve function adds a -different-
initial value.

Therefore, when starting at version 1 and evolving to version 2, you
get one set of initial values for the extent, but when you start at
version 2, you get a different set of initial values.

One of the new tests creates a new database at version 1 and evolves
it to version 2. The other test creates a new database directly at
version 2. Each one makes sure that the initial values of the Foo
extent are as the schema intends them to be in each scenario.

schevo.test.schema:

schevo.test.schema was unused, and thus has been removed along with
references to it.

schevo.test.base classes:

Database caching modified to properly support new functionality in
EvolvesSchemata-based tests.

_base_open now has schema_version keyword parameter.

New class-level attributes in EvolvesSchemata. Please see source code
for details. Those who currently use EvolvesSchemata in their test
classes should look at these details carefully and modify their tests
accordingly.

New command-line option for the "schevo db create" tool:
"--evolve-from-version".

Default behavior for "schevo db create" is now to create a new
database starting at the latest version, or the version specified with
-v. The old default behavior was to start at version 1, and evolve to
the latest version or that version specified with -v.

With the new option you can also create a database starting at an
arbitrary version and evolving to another arbitrary version. For
instance, starting at version 2 and evolving to version 4.

Handling of the 'latest' alias for "schevo db create" and "schevo db
evolve" has also been cleaned up, and there are two new helper
functions at schevo.schema.latest_version and
schevo.schema.schema_filepath to assist with this.

Matthew Scott

unread,
Apr 25, 2007, 10:19:39 PM4/25/07
to Schevo

Matthew Scott wrote:
> Schevo 3.1a1dev-r3125 has been pushed to the cheeseshop, with binary
> eggs for OSX and Windows.

Per some in-the-wild testing (thanks vilesyn!) I have a hunch that the
binary eggs for OSX are broken. I'm making a ticket for this to
remind myself to remove those eggs and correct this problem.

Somehow, it seems that an older version of files in "schevo.mt" has
been included in the egg, which causes "from schevo.database import
dummy_lock" to occur (which is no longer in that location, and thus
fails) and also causes "from schevo.mt.dummy import dummy_lock" to
fail (which should be in that location, but isn't).

Matthew Scott

unread,
Apr 29, 2007, 2:07:30 AM4/29/07
to Schevo

On Apr 25, 9:19 pm, Matthew Scott <gldns...@gmail.com> wrote:
> Per some in-the-wild testing (thanks vilesyn!) I have a hunch that the
> binary eggs for OSX are broken. I'm making a ticket for this to
> remind myself to remove those eggs and correct this problem.


http://schevo.org/ticket/50 is now fixed.

Reply all
Reply to author
Forward
0 new messages