> > Why not just use util.Dict (defaulting to dict) instead of {}?
> >
> > Then whoever wants, replaces that with Ordered one and voila, all
> > things get repeatable, if a little slower.
>
> the ordering of the data sent to the sort should not affect the
> outcome of the program. therefore its important to test all kinds
> of orderings to ensure that the initial lists of dependencies are
> correct. while you can hardcode the internal datastructures to use
> a deterministic ordering, that says nothing about the order in
> which the calling application inserts records into the UOW, which
> will then change the ordering anyway.
well, if one wants deterministic behavior all-over the chain, then one
should feed SA with deterministic data as _first_ thing, and just
then expect something.
This is about the 2 levels of testing:
- one, on the level of SQL, where ordering etc does matter; this
sort-a tests SA _and_ one's-own-usage of it for correctness of the
conversion to-sql and back
- two, on the app/persistency/orm level, where u want the data in to
match the data out no-matter-what's-in-between, is it sql or txt file
or someone writing on a stone-plate. A thorough test here would also
include writing on one machine and reading on another...
All them ordering problems come on level one - while they should NOT
matter on level 2.
It is not exactly/only in the topology-sort; it's all over. Any
SQL-echo of - tables, columns, inserts, props - whatever - will
change the next time u change the status of the machine.
i.e. a unittest which compares SQL-output, or most other SA-log, is
hardly possible. (Object id's/adresses which will also change do not
matter - a simple identity-map filter takes care of those easily).
for example, i've hacked dict to ordereddict in 6-7 choosen places,
and this covered ~80% of the cases; but i still have cases which give
differently ordered SQL everytime - i've missed something.
i don't have _enough_ internal knowledge of SA, hence finding which
dicts are important for ordering and which not, takes big time - and
time is a scarce resource; so i'll probably just mass-replace them
all.
> i think my --reversetop solution will be sufficient for now, ive
> seen lots and lots of these issues in the past year and a half and
> a combination of testing with "straight/reverse" will pretty much
> bring all of them out.
okay, when u feel ready to replace the {} with util.Dict, just yell,
i'll prepare the patch.
> > i mentioned this dictionary-order on my ramblings some weeks ago;
> > then u didnt take it into account.
>
> because i stop reading rambles after 50-60 words or so, and the
> stress of glossing over the rest generally causes me to forget
> words 30-60 as well.
hmmm. so u prefer problems one by one, or in a big list?
within 2 weeks we've fixed most of those mentioned there (see the end
of it)... those which i do care about. Some still remain:
polymorphics - are u ready to debug again (-:)? ticket 452.
Other's i don't care - e.g. it does matter if engine is bound or not
before doing tables - some cases work only if it is bound beforehand;
or doing the 3rd non-primary mapper does require a pre-build
_polymorphic_map, etc.
awww what a long post again
ciao
svil
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
