se/SE/schema/default_db_xml_cache/p5_obj_vars_triggers.xsl

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:p5_obj_vars_triggers="http://biuro.biall-net.pl/xmlschema_procesy5/default_db_xml_cache/p5_obj_vars_triggers.xsd"
    xmlns:system_cache__resources_tree_generate_xsl_required_occurs_raport="http://biuro.biall-net.pl/xmlschema_procesy5/system_cache/resources_tree_generate_xsl_require_occurs_raport"
    xmlns:system_cache__appinfo="http://biuro.biall-net.pl/xmlschema_procesy5/default_db_xml_cache/appinfo.xsd"
    exclude-result-prefixes="xs"
    version="2.0">
    <!-- @2016-01-15 template do stworzenia triggerow : plan : 
    (notepad a.binder) SSO procesy5 : koncepcja strategii integracji obiektow relacyjnych przetwarzanych xsd/xsl . 

niezbedne jest posiadanie wiedzy jakim typem obiektu jest dany element w bazie, aby wiadome bylo jakie przy imporcie maja sie stworzyc do niego instancje.
To pole zwyczajowo jest ustalone jako CRM_LISTA_ZASOBOW_ID - przyjalbym chyba to pole jako domyslne dla calosci systemu.
na etapie tworzenia kodu php lub triggerow jest konieczne poznanie tych struktur - do generowania jest potrzebna tabela  CRM_LISTA_ZASOBOW.xml - mam takową i już na niej się bawiłem w przetwarzanie. Pokazuje tylko komplikacje.
struktura triggerow by wygladala tak: after insert - trigger by oczekiwal konkretnych typow ID_ZASOBU i na tej podstawie wykonywal by funkcje np. new_default_objects_x3A_device - gdzie funkcja by oczekiwala w zaleznosci od typu i tworzyla odpowiednia ilosc tabel instancyjnych, przelatywala by wszystkie kolumny zidentyfikowane w obiekcie i dodawala je do siebie. 
W przypadku kilku telefonow lub rekordow po spacji, system moglby od razu wrzucac je jako kolejne occurs (jezeli w obiekcie telefon bedzie miec maxOccurs=3 to warto aby bylo zaznaczone w elemenecie, z default_db:schema, ze jest tam string z separatorem - jako tokens - to mogloby byc przerobione w locie.
after edit - leci po wszystkich kolumnach zidentyfikowanych i aktualizuje wartosci - poprzez wprowadzenie kolejnych wartosci , a starych zaznaczenie jako DELETED
jak się zmieni typ ? trzeba przeanalizowac jakie dziedziczenia trzeba przepisac jako inne typy - biorac pod uwage mozliwosc inncyh relacji innego typu - prawdopodobnie nie powinno sie dac zmienic type, jezeli inny type ma inne relacje oraz jezeli jakies relacje juz byly. Zatem trigger - before update. 
@2016-01-15 a.binder
    -->
    
    <!--
    <xsl:template match="system_cache__resources_tree_generate_xsl_required_occurs_raport:detect_resource_type" mode="p5_obj_vars_triggers:create_db_sync_triggers">
        test p5_obj_vars_triggers:create_db_sync_triggers
        <xsl:apply-templates mode="#current"/>
    </xsl:template>
    
    <xsl:template match="system_cache__appinfo:detect_first_ref_to_native_procesy5_table" mode="p5_obj_vars_triggers:create_db_sync_triggers">
        test p5_obj_vars_triggers:create_db_sync_triggers2
        <xsl:apply-templates mode="#current"/>
    </xsl:template>
    
    <xsl:template match="*" mode="p5_obj_vars_triggers:create_db_sync_triggers"></xsl:template>
    -->
</xsl:stylesheet>