Am 09.03.2017 um 13:17 schrieb Cédric Krier:
> On 2017-03-09 12:46, Ul wrote:
>> My query now looks like:
>> SELECT (("a"."id" << 5) + "b"."id") AS "id", "a"."create_uid" AS
>> "create_uid", "a"."create_date" AS "create_date",
>> "a"."write_uid" AS "write_uid", "a"."write_date" AS
>> "write_date", "a"."uom" AS "uom", "a"."quantity" AS "quantity",
>> "a"."lot" AS "from_lot", "b"."lot" AS "to_lot"
>> FROM "stock_move" AS "a"
>> INNER JOIN "stock_move" AS "b"
>> ON ("a"."production_input" = "b"."production_output")
>> WHERE (("a"."lot" > 0) AND ("b"."lot" > 0))
>> UNION
>> SELECT (("a"."id" << 5) + "a"."id") AS "id", "a"."create_uid" AS
>> "create_uid", "a"."create_date" AS "create_date", "a"."write_uid"
>> AS "write_uid", "a"."write_date" AS "write_date", "a"."uom" AS
>> "uom", "a"."quantity" AS "quantity", "a"."supplier_lot" AS
>> "from_lot", "a"."lot" AS "to_lot"
>> FROM "stock_move" AS "a"
>> WHERE (("a"."lot" > 0) AND ("a"."supplier_lot" > 0))
>
> I still do not see the point to make an union.
> Your first select could be just the table of a Many2Many relation and
> you just show the moves as a tree using this Many2Many.
If you just follow the lot relations made by production, you are right.
But as i explained to Sergi, i added a aditional field 'supplier_lot' to
move, that is filled by shipment in, as i do not want to use the Lot
numbers of the supplier internally, but of cause have to track my lots
back to them.
> And of course you have the reverse Many2Many to go the other way.
I did both directions with two different views on this table.
>
> For the unique id, it is pretty simple to generate unique id with fixed
> number of ids, see model.Union.union_shard.
I didn't know about yet. Can you tell me where it is used already, to
see an example?
My problem with double ids is not about the union, it is mainly from the
join in the first select-clause, so i don't know if this tool made for
union is solving it.
>
> Also I do not see the point of the clause "lot > 0", if you want just
> move with lot, use must use "lot IS NOT NULL".
when playing with the queries i once got an error because of wrong
datatype in python. Like this it worked.
> But I think it is good to
have the tree even if there is not lot.
I dont see the sense, as i want to see the relations of lots. having a
move without lot gives no information about a lot, but i need error
handling for missing attributes.
--
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/8feb49fe-bf67-3e48-d542-80cf4e8490c0%40gmx.de.
