.. _orm_genropy/tables/subtable:

Subtable
========




La ``subtable`` permette di creare un *subset* di record all'interno di una table. Questa prassi ha il seguente vantaggio:

- i record (i principali e il subset) si trovano all'interno della stessa tabella, di conseguenza sono individuabili contemporaneamente dalle operazioni di lettura.
- allo stesso tempo, è possibile filtrare determinati risultati sulla base del criterio specificato

La *subtable* è così definita::

  class Table(object):
    def config_db(self,pkg):
        tbl = pkg.subtable('prodotto_kit', maintable='fatt.prodotto', relation_name='kit_prodotto', name_long='Prospect', name_plural='Prospect', caption_field='nome_cognome')
        
La struttura della *subtable* condivide in toto lo schema delle  :ref:`colonne<orm_genropy/orm_genropy/model/column>`  della ``maintable``, salvo permetterne l'aggiunta o la customizzazione analogamente a quanto avviene con le tabelle tradizionali. È infatti possibile aggiungere specifiche colonne della subtable con la sintassi::
  
  subtbl = pkg.subtable('prospect', name_long='Prospect'...)
  subtbl.column('cognome_nome', name_long='Cognome nome)
  
dove il nome *subtbl* è puramente indicativo e da intendersi a scopo didattico.

*Subtable* e *sysfields*
~~~~~~~~~~~~~~~~~~~~~~~~
Internamente la  :ref:`gnrdbsetup<orm_genropy/orm_genropy/model>` , laddove presente una *subtable*, andrà a creare un'altra  :ref:`colonna di sistema<orm_genropy/orm_genropy/model/column/sysFields>`  rispetto a quelle standard, ``__subtable``, che verrà popolata con il nome della *subtable* (nella forma *pkg.table*). 

*Subtable* e *trigger*
~~~~~~~~~~~~~~~~~~~~~~
Può capitare di non voler innescare dei  :ref:`trigger<orm_genropy/triggers>`  con i record di una table, o viceversa di farli scattare solo quando ci troviamo in una determinata condizione. Si pensi per esempio a tutti gli automatismi contabili che si verificano nel caso di un cliente nei confronti del quale c'è una fatturazione regolare, rispetto a quanto avviene per un cliente *prospect*.

Per gestire questa casistica si può utilizzare le *subtable*. La *subtable* permette infatti di definire, direttamente nel model, dei suoi *trigger*, in modo del tutto analogo a quanto avviene per le tabelle classiche.

Risorse
~~~~~~~
Le *subtable* sono indipendenti dalle *maintable* anche per quanto riguarda le risorse. Sarà quindi possibile creare delle risorse *th* e richiamarle nei vari `TableHandler <https://docs.genropy.org/tablehandler/>`_.

Inoltre, sono disponibili delle `sections automatiche <https://www.genropy.org/blog/come-arricchire-le-viste-con-le-sections/>`_ per visualizzare, nella risorsa della *maintable*, una *section* con i valori della tabella principale e della *subtable*. Le *sections* sono così definite::

  def th_top_toolbarsuperiore(self,top): 
    top.slotToolbar('*,sections@subtables,*')

.. raw:: html

 <hr>

**Parametri:**

+------------------------+------+--------------------------------------------------+
|     Nome parametro     | Tipo |                   Descrizione                    |
+========================+======+==================================================+
|maintable               |T     |Permette di indicare la tabella di origine per la |
|                        |      |struttura della subtable (es:                     |
|                        |      |maintable='fatt.prodotto')                        |
+------------------------+------+--------------------------------------------------+
|relation_name           |T     |Permette di indicare come verranno rinominati i   |
|                        |      |relation_name presenti nella tabella principale,  |
|                        |      |per seguire le relazioni verso la sola subtable   |
|                        |      |(es: relation_name='kit_prodotto')                |
+------------------------+------+--------------------------------------------------+

.. sectionauthor:: Davide Paci