ITAGAKI Takahiro wrote:
> The chained triggers would have better flexibilty, and the auto expanding
> trigger would have better usability. I'm not sure about performance
> because expanding child partitions is not always faster than chained
> calls of triggers.
>
> I think chained triggers are hard to maintain. If we drop one of partition
> tables, we need to reconnect the single-linked-list of the triggers.
>
When you drop one child table, you would also have to drop the trigger
that has the same name on the parent table. This does not seem too hard
but I may be missing something.
>>> server says "INSERT 0 row" though rows are inserted into child tables.
>>>
>> Technically this is correct since 0 rows were inserted in the parent
>> table.
>>
> Yes, but users expect non-0 result normally. Some O/R mapping tools
> also checks the result exactly and raises errors (it could be turned
> off, but default is on).
>
If the O/R mapping tool is also creating the table it should be aware of
the semantics specifics to partition. But your comment is well taken,
this seems counterintuitive and against most API semantics to return 0
when the number of inserted rows is expected. This would certainly
require some additional hooks to return the proper value.
Best regards,
Emmanuel
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu@frogthinker.org
Skype: emmanuel_cecchet