{5} Assigned, Active Tickets by Owner (Full Description) (30 matches)

Testing SQLite 'typeless'...
SQLite Version: 3.3.3
test_1_model (zoo_fixture.ZooTests) ... ok
test_2_populate (zoo_fixture.ZooTests) ... ok
test_3_Properties (zoo_fixture.ZooTests) ... ok
test_Aggregates (zoo_fixture.ZooTests) ... ok
test_DB_Introspection (zoo_fixture.ZooTests) ... FAIL
test_Editing (zoo_fixture.ZooTests) ... ok
test_Engines (zoo_fixture.ZooTests) ... ok
test_Expressions (zoo_fixture.ZooTests) ... ok
test_Iteration (zoo_fixture.ZooTests) ... ok
test_Multirecall (zoo_fixture.ZooTests) ... ok
test_Multithreading (zoo_fixture.ZooTests) ... ok
test_Subclassing (zoo_fixture.ZooTests) ... ok
test_autoclass (zoo_fixture.ZooTests) ... ok
test_autosource (zoo_fixture.ZooTests) ... ok
test_numbers (zoo_fixture.ZooTests) ... precision: 1 2 4 8FAIL
testzzzz_Schema_Upgrade (zoo_fixture.ZooTests) ... ok

======================================================================
FAIL: test_DB_Introspection (zoo_fixture.ZooTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python24\Lib\site-packages\dejavu\test\zoo_fixture.py", line 814, in test_DB_Introspection
    self.assertEqual(s.db.python_type(idcol.dbtype), int)
AssertionError: <type 'str'> != <type 'int'>

======================================================================
FAIL: test_numbers (zoo_fixture.ZooTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python24\Lib\site-packages\dejavu\test\zoo_fixture.py", line 1019, in test_numbers
    self.fail("%s != %s prec=%s scale=%s" %
AssertionError: -1L != 4294967295L prec=8 scale=1

FAILED (failures=2)
 Ran zoo suite in: 0:01:08.078000

In Dejavu 2, sandboxes are much more optional. The on_memorize, on_recall and on_forget methods should be moved into SM.xrecall and SM.destroy, if only to protect users from updating unit data and forgetting to execute those triggers.

geniusql is designed to work with data types and formats as defined by the DB, but there's no real test yet for that--all the existing tests only cover the case where the Python model creates the DB schema, not the other way around.

Write some tests which exercise pulling the schema from the DB and making a model from that. The autoclass tests are a start, but don't cover e.g. what to do with a non-standard datetime format in SQLite.

Now that sandboxes are not the only way to interact with stores, move on_recall out of the sandbox class and into each leaf store (whenever a new Unit is instantiated).

Need to check each object on_memorize--make sure it isn't using an existing ID. This isn't a big problem for Units with Sequencers; it's those that don't have a Sequencer that need checking.

Any engine should have a feed. How to display the output is an issue.

The current one-unit-at-a-time lookup is really slow. Now that all stores support multirecall, we should change visit_TRANSFORM to use multirecall, maybe even a view, since all we need is the identity() of the far units at that time.

Probably with two-phase commit. The sandbox transaction methods would prepare all stores, then commit all stores. Not sure if using a store that doesn't support PREPARE should raise a warning or error.

See http://groups.google.com/group/turbogears/browse_frm/thread/c0a5bbfda0c3a6a7

Call it in Rewriter.code_object to get co_stacksize.

Some Units (e.g. Amor's vehicles) could use a sequencer which sorts all bare numbers to top, then alpha.

Writing chunks of code (like the following example) is somewhat redundant:

TripGroup._associations["MissionTrip"] = TripGroup.MissionTrip = GroupToTripAssociation()

Perhaps we could override Unit.__setattr__, __delattr__ to automatically add bound descriptors to Unit._associations and Unit.properties.