@2018-03 Bindera: propozycja dla bazowych dziedziczen do tworzenia patternow dla silnik a BI. Silnik BI potrzebuje konfiguracji, które obiekty są początkowe, które są końcowe oraz które są pomiędzy. Jest też czasami konieczność aby znać kolejność wyszukanych elementów. Zatem należy zdefiniować OD (było pracownicy), DO (było Kontrahenci) oraz ROW (było BI_audit_ENERGA_RUM_KONTRAHENCI_POWIAZANIA_row), ROW_object (było BI_audit_ENERGA_RUM_KONTRAHENCI_POWIAZANIA_row_object) oraz ewentualna abstrakcyjna definicja BI (było BI_audit_ENERGA_RUM_KONTRAHENCI_POWIAZANIA ) ewentualna abstrakcyjna definicja BI (było BI_audit_ENERGA_RUM_KONTRAHENCI_POWIAZANIA ) TODO jak rozroznic wyszukiwanie generalne dla wszystkich oraz dla niektorych? Moze lepiej aby bylo zawsze wiadome ktore elementy sa poddane analizie , a ktore nie, aby to kontrolowac - wiec zawsze bedzie ref Schema dla instancjonowania wyszukanych elementow Primary Mapowane do silnika BI dla glebokosci, uzyte w asserts dla unikalnych wyszukiwan typow Przykładowy label z primary KEY Dla patternow ktore wymagaja podania limitu konca - kontrola unikalnosci Primary Mapowane do silnika BI dla glebokosci, uzyte w asserts dla unikalnych wyszukiwan typow Rekursywnosc - dlugosc wyszukiwania scisle zwiazana z parametrem MaxDepth Abstrakcyjny przykladowy typowy model TODO chyba nie zawsze musi byc cokolwiek znaleizone? Opcjonalne wskazanie namespace celu lub/i konkretnych instancji Unikalność patternów - nie ma sensu aby kilkukrotnie definiować np PRACOWNICY jako OD Cel szukania unikalny namespace jeden raz Abstrakcyjny przykladowy typowy model