Am 14.02.2017 um 09:30 schrieb Sergi Almacellas Abellana:
> El 13/02/17 a les 21:57, Ul ha escrit:
>>
>> For usual data it works fine.
>> But it doesn't work with a tree were one leaf or knot shows up two times
>> at 2 different places.
>> in this Case I get an Error in the Client: "You try to read records that
>> don't exist anymore."
>>
>> I located the place were the error is triggered:
>> model/modelsql.py line 704 there is a check:
>> "if not len(fetchall) == len({}.fromkeys(sub_ids)):"
>> If i comment out the whole if clause or just the line calling the error
>> (line 717) it works fine.
>>
>> How important is this check? How much do i risk if i leave this
>> error-call disabeled?
>>
> 
> 
> This check says that you requested data for X records but the query only
> returned Y. Normally it is used to ensure that the user is allowed to
> read all the records he is trying to access. But I believe that in your
> case there is something in your sql query that prevents to return the
> correct data.
> 
> Do you mind sharing the query? So we investigate further which is
> causing the error.
> 
> 
> 

My query is:

WITH RECURSIVE "a"("id", "parent", "origin", "create_uid", "product",
        "create_date", "write_date", "write_uid", "lot", "rel_id",
        "lot_id") AS (
  SELECT 0, -1, "b"."origin" AS "origin", "b"."create_uid" AS
        "create_uid", "b"."product" AS "product", "b"."create_date" AS
        "create_date", "b"."write_date" AS "write_date",
        "b"."write_uid" AS "write_uid", "b"."id" AS "lot", "c"."id" AS
         "rel_id", "b"."id" AS "lot_id"
  FROM "stock_lot" AS "b"
    LEFT JOIN "stock_lot_relation" AS "c"
    ON ("b"."id" = "c"."from_lot")
  WHERE ("b"."id" = 10)
UNION
  SELECT "c"."id", "a"."id", "b"."origin" AS "origin", "b"."create_uid"
        AS "create_uid", "b"."product" AS "product", "b"."create_date"
        AS "create_date", "b"."write_date" AS "write_date",
        "b"."write_uid" AS "write_uid", "b"."id" AS "lot", "c"."id" AS
        "rel_id", "b"."id" AS "lot_id"
  FROM "stock_lot" AS "b"
    LEFT JOIN "stock_lot_relation" AS "c"
    ON ("b"."id" = "c"."from_lot"),
    "a" AS "a"
  WHERE ("c"."to_lot" = "a"."lot_id")
)
SELECT "a".* FROM "a"

as i told, with a strait tree it works well, but if some lots show up at
different places in the tree, some records have to be displayed several
times.

here is an example tree:

Lot         a.id  relation.id  lot.id  parent

Lot11        0         -          10     -1
  Lot10      7         7          9      0
    Lot3     1         1          3      7
      Lot1   11        11         1      1
      Lot2   12        12         2      1
    Lot6     2         2          5      7
    Lot4     3         3          4      7
    Lot7     4         4          6      7
    Lot8     5         5          7      7
  Lot3       8         8          3      0
    Lot1     11        11         1      1
    Lot2     12        12         2      1

so as Lot3 is used twice the lines with relation.id 11 and 12 show up
twice.

i placed a print command right after 'if' in model/modelsql.py line 704
that gives me different output depending on what level of the tree i unfold:
len(fetchall): 9 != len({}.fromkeys(sub_ids)): 7
len(fetchall): 4 != len({}.fromkeys(sub_ids)): 2

so i suppose in 'fetchall' are all lines that are returned by the
database and in the second clause every id can only show up once as it
is a dict.

so the problem is quite clear, the question is how to deal with it the
proper way.
One way that works is to comment out the error-message, but this could
be a problem in other cases this error was intended for. Could this be a
relevant risk?
The cleaner way would be to change the if clause, to only apply in the
intended cases. But i don't know how to catch all cases that it should
without knowing what was in mind creating the clause and understanding
the whole context. And i don't really have the time to dig much deeper
right now if it isn't important.

I hope that gives a good picture of the situation...

best Regards,
Ulrich

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/738bfbed-061f-d46f-8395-12c30839c6f4%40gmx.de.

Reply via email to