On Aug 18, 11:40 pm, Philip Jenvey pjen...@underboss.org wrote:
There's a README.unittests that should tell you all you need to know.
Basically you need a test database, possibly a 'test_schema' depending
on the db (see the bottom of the doc), then run:
nosetests -v --dburi=some://uri/db
Marin wrote:
On Aug 18, 11:40 pm, Philip Jenvey pjen...@underboss.org wrote:
There's a README.unittests that should tell you all you need to know.
Basically you need a test database, possibly a 'test_schema' depending
on the db (see the bottom of the doc), then run:
nosetests -v
On Aug 18, 2009, at 12:47 AM, Marin wrote:
I reported the bug a year ago. It seems nobody is interested in fixing
it.
So, this is my first try, but i don't know how to use the regression
test to see if it is correct. Can anybody help me?
There's a README.unittests that should tell you all
I was trying to do something yesterday evening and I found something
strange. After running this code:
q = Q()
for j in range(1):
a = A()
a.Q = q
a.C = WC()
I get this graph edges (tuples):
import pprint
ppp = pprint.PrettyPrinter(indent=4)
ppp.pprint([(x.class_,
On Jun 23, 2008, at 4:18 AM, Marin wrote:
I was trying to do something yesterday evening and I found something
strange. After running this code:
q = Q()
for j in range(1):
a = A()
a.Q = q
a.C = WC()
I get this graph edges (tuples):
import pprint
ppp =
Thx for the info. I took a short look at the code yesterday, and I
can't understand why do you use the _organize_as_tree function. The
ordered list of nodes that the topological sort returned should be
enough for the flush. Maybe I am missing the idea behind the code (but
that is OK since this is
On Jun 22, 2008, at 5:38 AM, Marin wrote:
Thx for the info. I took a short look at the code yesterday, and I
can't understand why do you use the _organize_as_tree function. The
ordered list of nodes that the topological sort returned should be
enough for the flush. Maybe I am missing the
It sounds like a typical case of YAGNI.
But, if the code works with the tree structure, could it be fix by
just supplying the sorted list instead of the tree? As a list could be
seen as a flat tree, the algorithm should work if the organize_as_tree
does nothing.
On Jun 22, 2008, at 12:08 PM, Marin wrote:
It sounds like a typical case of YAGNI.
But, if the code works with the tree structure, could it be fix by
just supplying the sorted list instead of the tree? As a list could be
seen as a flat tree, the algorithm should work if the
Heh, same here. The weekend is over and I have to go back to other
stuff. I'll try to do something if could find the time.
yes, that was the idea. Didn't work for some reason, but I didn't try
that hard.
--~--~-~--~~~---~--~~
You received this message because
I know that is complicated, but I'll still take a look at it.
--~--~-~--~~~---~--~~
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
OK, you should work with the 0.5/trunk. Major changes to UOW are
only going to go into 0.5, and the code is slightly simplified in 0.5
already.
On Jun 21, 2008, at 2:56 AM, Marin wrote:
I know that is complicated, but I'll still take a look at it.
Attached is one I made using what it looks like the relationships are
based on your test code. It inserts 3502 rows into a SQLite database
without issue.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
yes it does (sa4) but needs something like:
import sys
sys.setrecursionlimit(200)
it gets slower and slower while running until it breaks.
On Friday 20 June 2008 21:41:18 Marin wrote:
[sqlalchemy] Re: Problem:maximum recursion depth exceeded
From:
Marin [EMAIL PROTECTED]
To:
sqlalchemy
Should I report this as a ticket on the SA trac site?
--~--~-~--~~~---~--~~
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,
On Jun 20, 2:41 pm, Marin [EMAIL PROTECTED] wrote:
I hope I'll hear from you if you replicate the error.
its a bug with strong heisenbug tendencies which ultimately involves a
very deep dependency graph being generated, which is what it looked
like all along. The depth is a result of every
I see that someone just copy/paste that code I wrote in the ticket
1081. I'll try to take a look and fix it myself this weekend if I
could spare the time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy
fixing this issue is non-trivial; the tree formation code is very
intricate, which is why I'd like to dump it altogether; its already
been removed from parts of the UOW's process. But dumping it requires
that the UOW's execute plan at the inter-row-dependency level work in
a different
On Jun 18, 2008, at 4:16 AM, Marin wrote:
I get this error when i try to execute the folowing code (Test,
Section, Question, Answer are mepped tables):
test = Test()
section = Section()
section.Test=test
for i in range(60):
q=Question()
q.Section=section
for j in range(6)
cant really tell unless you provide a fully functional, as simple as
possible test case, preferably against sqlite, which can be run with
no dependencies.
I'll try to make one. I tried to fix it doday and got that the next
code does not produce the error:
test = Test()
section = Section()
the error you're getting suggests an unusually long chain of
dependencies between individual rows. There is a recursive element to
the way that a flush plan is executed, but it generally is a shallow
recursion.Your stack trace isn't making it clear where the bulk of
the recursion is
21 matches
Mail list logo
