🚀 go-pugleaf

W dniu 2018-01-30 o 15:25, konsul41@wp.pl pisze:
/ciach/

> Jak w ciele takiej funkcji pobrać nazwę dll/bpl która ją wywołuje?
https://stackoverflow.com/questions/258727/display-the-call-stack-in-a-delphi-win32-application

Ja używam Eureki do tego...
A to, powiem szczerze, widzę pierwszy raz na oczy :)
http://www.dimusware.com/products/excmagic/index.html

-- 
wloochacz

Nie do końca o to chodziło
ponieważ
try
   //do something
     raise Exception.Create('Something bad happened...');
   except
     on e: exception do
     begin
     //rollback a transaction or whatever i need to do here
       MessageDlg('An error has occurred!' + #13#10 + e.Message + #13#10 
+ 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError, [mbOK], 0);
     end;  //except
   end;  //try-except

e.StackTrace jest puste  ---> '' .


W zasadzie potrzebuję uchwyt do załadowanej dll lub BPL.
Pytanie wywoływana funkcja działa w "przestrzeni" w sensie modułu 
uruchamianego bpl/dll czy EXE?
Inaczej czy wyszukiwana funkcja działa jako część bpl/dll czy exe?

Potrzebuję to do tego.
Plugin może poprosić o utworzenie tabeli w bazie ale nazwa tabeli musi 
być poprzedzona nazwą modułu, aby nie było dostępu do tabel o 
ograniczonym dostępie dla pluginów.
A może można to lepiej zrealizować?

Nie o t mi chodziło ale
EXE
function CreateTableForplugin(moduleInstance : HINST; sql: WideString): 
Boolean;
begin
   ShowMessage(System.SysUtils.GetModuleName(moduleInstance));
end;

bpl/DLL
var CreateTableForplugin : function (moduleInstance : HINST; sql : 
WideString):Boolean;
begin
   CreateTableForplugin:=GetProcAddress(MainInstance, 
'CreateTableForplugin');
   if (@CreateTableForplugin<>nil) then CreateTableForplugin(HInstance,'');
...

end;



Dostaję nazwę modułu.
Działa tak jak zakładałem.
Niestety trzeba podawać HInstance co teoretycznie może prowadzić do 
nadużyć ale na razie musi tak zostać.

On Tue, 30 Jan 2018 20:07:58 +0100, Karol wrote:

> Dostaję nazwę modułu.
> Działa tak jak zakładałem.
> Niestety trzeba podawać HInstance co teoretycznie może prowadzić do 
> nadużyć ale na razie musi tak zostać.

Spróbuj użyć FindHInstance z adresem np. metody z DLLki.

-- 
pozdrawiam
Roman Tyczka

W dniu 31-01-2018 o 16:34, Roman Tyczka pisze:
> On Tue, 30 Jan 2018 20:07:58 +0100, Karol wrote:
> 
>> Dostaję nazwę modułu.
>> Działa tak jak zakładałem.
>> Niestety trzeba podawać HInstance co teoretycznie może prowadzić do
>> nadużyć ale na razie musi tak zostać.
> 
> Spróbuj użyć FindHInstance z adresem np. metody z DLLki.
> 
To nie ma znaczenia. DLL To plugin i nie wiadomo kto co napisze.
Zależało mi na tym aby uniezależnić się od parametru podawanego z dll.
Nie ma znaczenia czy podam adres z wnętrza dll czy HInstance dll-ki.
Przechowuje adresy modułów (LoadLibrery...)i mógłbym je porównać ale 
trzeba mieć z czymś porównać.

W dniu 2018-01-30 o 17:51, Karol pisze:
> Nie do końca o to chodziło
> ponieważ
> try
>    //do something
>      raise Exception.Create('Something bad happened...');
>    except
>      on e: exception do
>      begin
>      //rollback a transaction or whatever i need to do here
>        MessageDlg('An error has occurred!' + #13#10 + e.Message + #13#10 
> + 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError, [mbOK], 0);
>      end;  //except
>    end;  //try-except
> 
> e.StackTrace jest puste  ---> '' .

Dokładnie o to chodziło, a skoro stack jest pusty, to źle go używasz.

> W zasadzie potrzebuję uchwyt do załadowanej dll lub BPL.
> Pytanie wywoływana funkcja działa w "przestrzeni" w sensie modułu 
> uruchamianego bpl/dll czy EXE?
> Inaczej czy wyszukiwana funkcja działa jako część bpl/dll czy exe?
Tak by design, to jest tak...
dla BPL w kontekście EXE.
dla DLL w kontekście DLL.

> Potrzebuję to do tego.
> Plugin może poprosić o utworzenie tabeli w bazie ale nazwa tabeli musi 
> być poprzedzona nazwą modułu, aby nie było dostępu do tabel o 
> ograniczonym dostępie dla pluginów.
> A może można to lepiej zrealizować?
Tak, może i lepiej można... Ale, albo idziesz w stronę konwencji (to co 
opisałeś z nazwą modułu dla tabeli), ale to trzeba naprawdę dobrze 
zaprojektować.
Albo idziesz w stronę konfiguracji, czyli jakiś metadanych określających 
co jak i dlaczego.

A tak poza tym, to nie podoba mi się ten pomysł zakładania tabeli dla 
modułu przez moduł na podstawie jego nazwy...
To jest, imo, zakręcony temat, no chyba że te Twoje moduły nie posiadają 
zależności do innych modułów - to wtedy i tylko wtedy, może...

Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura 
bazy danych jest dostarczona cała w pełnej konfiguracji.
Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie 
używa jakiś tam obiektów w bazie danych.
A że baza ma tabele, które są puste i nieużywane?
I co z tego?

-- 
wloochacz

On Thu, 1 Feb 2018 08:33:47 +0100, konsul41@wp.pl wrote:

>>> Dostaję nazwę modułu.
>>> Działa tak jak zakładałem.
>>> Niestety trzeba podawać HInstance co teoretycznie może prowadzić do
>>> nadużyć ale na razie musi tak zostać.
>> 
>> Spróbuj użyć FindHInstance z adresem np. metody z DLLki.
>> 
> To nie ma znaczenia. DLL To plugin i nie wiadomo kto co napisze.
> Zależało mi na tym aby uniezależnić się od parametru podawanego z dll.

No i to właśnie proponuję, aby zrobić. Czyli, żeby HInstace nie oczekiwać
od DLL tylko pobrać na poziomie EXE.

> Nie ma znaczenia czy podam adres z wnętrza dll czy HInstance dll-ki.
> Przechowuje adresy modułów (LoadLibrery...)i mógłbym je porównać ale 
> trzeba mieć z czymś porównać.

Tego nie rozumiem.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-02-01 o 10:39, wloochacz pisze:
> W dniu 2018-01-30 o 17:51, Karol pisze:
>> Nie do końca o to chodziło
>> ponieważ
>> try
>>    //do something
>>      raise Exception.Create('Something bad happened...');
>>    except
>>      on e: exception do
>>      begin
>>      //rollback a transaction or whatever i need to do here
>>        MessageDlg('An error has occurred!' + #13#10 + e.Message +
>> #13#10 + 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError,
>> [mbOK], 0);
>>      end;  //except
>>    end;  //try-except
>>
>> e.StackTrace jest puste  ---> '' .
>
> Dokładnie o to chodziło, a skoro stack jest pusty, to źle go używasz.
>
>> W zasadzie potrzebuję uchwyt do załadowanej dll lub BPL.
>> Pytanie wywoływana funkcja działa w "przestrzeni" w sensie modułu
>> uruchamianego bpl/dll czy EXE?
>> Inaczej czy wyszukiwana funkcja działa jako część bpl/dll czy exe?
> Tak by design, to jest tak...
> dla BPL w kontekście EXE.
> dla DLL w kontekście DLL.
>
>> Potrzebuję to do tego.
>> Plugin może poprosić o utworzenie tabeli w bazie ale nazwa tabeli musi
>> być poprzedzona nazwą modułu, aby nie było dostępu do tabel o
>> ograniczonym dostępie dla pluginów.
>> A może można to lepiej zrealizować?
> Tak, może i lepiej można... Ale, albo idziesz w stronę konwencji (to co
> opisałeś z nazwą modułu dla tabeli), ale to trzeba naprawdę dobrze
> zaprojektować.
> Albo idziesz w stronę konfiguracji, czyli jakiś metadanych określających
> co jak i dlaczego.
>
> A tak poza tym, to nie podoba mi się ten pomysł zakładania tabeli dla
> modułu przez moduł na podstawie jego nazwy...
> To jest, imo, zakręcony temat, no chyba że te Twoje moduły nie posiadają
> zależności do innych modułów - to wtedy i tylko wtedy, może...
>
> Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura
> bazy danych jest dostarczona cała w pełnej konfiguracji.
> Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie
> używa jakiś tam obiektów w bazie danych.
> A że baza ma tabele, które są puste i nieużywane?
> I co z tego?
>

Tabelę zakładałby EXE dodając nazwę modułu(wtyczki) jako prefix do nazwy 
tabeli.
Takie zakładanie to na przyszłość, alternatywą jest localsql w jakimś 
katalogu (pluginu).
Pluginy (obce nie moje) nie mają bezpośredniego dostępu do bazy, ale 
muszą gdzieś gromadzić dane.

> 
> Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura 
> bazy danych jest dostarczona cała w pełnej konfiguracji.
> Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie 
> używa jakiś tam obiektów w bazie danych.
> A że baza ma tabele, które są puste i nieużywane?
> I co z tego?
> 
> -- 
> wloochacz

Ten sposób uniemożliwiasz przebudowę samej bazy danych /a w momencie tworzenia musi być przemyślana do końca/ ja robię to w taki sposób że w bazie jest tabela  która zawiera nr wersji bazy danych i przy każdorazowym otwarciu programu, sprawdzany jest numer bazy danych oraz na moim serwerze czy jest nowy numer. Ewentualna zmiana jest powiązana z nowym plikiem wymuszającym zmiany w bazie danych / np.  nowa tabela , wyzwalacze itp wraz z zależnościami w stosunku z pozostałymi tabelami/ Ten sposób pozwala mi na zmianę struktury samej bazy. A  dwa moduły jeden z treścią SQL-a o drugi ze sposobem jego interpretacji i działaniem na samej bazie nie stanowią jakiegoś krytycznego obciążenia pamięci.

jasiek 

W dniu 2018-02-02 o 10:56, jasiek pisze:

> Ten sposób uniemożliwiasz przebudowę samej bazy danych /a w momencie tworzenia musi być przemyślana do końca/ ja robię to w taki sposób że w bazie jest tabela  która zawiera nr wersji bazy danych i przy każdorazowym otwarciu programu, sprawdzany jest numer bazy danych oraz na moim serwerze czy jest nowy numer. Ewentualna zmiana jest powiązana z nowym plikiem wymuszającym zmiany w bazie danych / np.  nowa tabela , wyzwalacze itp wraz z zależnościami w stosunku z pozostałymi tabelami/ Ten sposób pozwala mi na zmianę struktury samej bazy. A  dwa moduły jeden z treścią SQL-a o drugi ze sposobem jego interpretacji i działaniem na samej bazie nie stanowią jakiegoś krytycznego obciążenia pamięci.

Podobnie działa Liquibase, jeśli chcesz coś zmienić w bazie, to tworzysz 
changeset odwołujący się do skryptów SQL. Wykonanie changeseta jest 
zapisywane w bazie i po raz drugi się nie wykona.


-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

W dniu wtorek, 30 stycznia 2018 17:51:59 UTC+1 użytkownik Karol napisał:
> Nie do końca o to chodziło
> ponieważ
> try
>    //do something
>      raise Exception.Create('Something bad happened...');
>    except
>      on e: exception do
>      begin
>      //rollback a transaction or whatever i need to do here
>        MessageDlg('An error has occurred!' + #13#10 + e.Message + #13#10 
> + 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError, [mbOK], 0);
>      end;  //except
>    end;  //try-except
> 
> e.StackTrace jest puste  ---> '' .
> 
>..
taka mała uwaga>

wiersz z raise.. powinien być w sekcji except inaczej się nie wykona, jeśli błąd wystąpi przed tą linią kodu.

Paweł

W dniu niedziela, 4 lutego 2018 09:29:44 UTC+1 użytkownik zpksoft napisał:
> W dniu wtorek, 30 stycznia 2018 17:51:59 UTC+1 użytkownik Karol napisał:
> > Nie do końca o to chodziło
> > ponieważ
> > try
> >    //do something
> >      raise Exception.Create('Something bad happened...');
> >    except
> >      on e: exception do
> >      begin
> >      //rollback a transaction or whatever i need to do here
> >        MessageDlg('An error has occurred!' + #13#10 + e.Message + #13#10 
> > + 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError, [mbOK], 0);
> >      end;  //except
> >    end;  //try-except
> > 
> > e.StackTrace jest puste  ---> '' .
> > 
> >..
> taka mała uwaga>
> 
> wiersz z raise.. powinien być w sekcji except inaczej się nie wykona, jeśli błąd wystąpi przed tą linią kodu.
> 
> Paweł

Hm.. właściwie nie wiem co jest w 

 //do something

W każdym razie dyrektywa raise powoduje przeskoczenie do sekcji except gdzie jako e.Message dostaniesz 'Something bad happened...'

Być może kod jest dobry tylko jako pseudukod nieco mnie zmylił.

Paweł

W dniu piątek, 2 lutego 2018 10:56:03 UTC+1 użytkownik jasiek napisał:
> > 
> > Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura 
> > bazy danych jest dostarczona cała w pełnej konfiguracji.
> > Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie 
> > używa jakiś tam obiektów w bazie danych.
> > A że baza ma tabele, które są puste i nieużywane?

> Ten sposób uniemożliwiasz przebudowę samej bazy danych /a w momencie tworzenia musi być przemyślana do końca/ ja robię to w taki sposób że w bazie jest tabela  która zawiera nr wersji bazy danych i przy każdorazowym otwarciu programu, sprawdzany jest numer bazy danych oraz na moim serwerze czy jest nowy numer. 

Czegoś nie rozumiem. A co ma jedno do drugiego?
Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
Kurcze - ja mam tak samo jak wloochacz i nie wyobrażam sobie utrzymania systemu gdzie np. każdy plugin czy dllka mi miesza po bazie danych robiąc swoje aktualizacje struktury.
Wolę mieć jedną dostarczaną z programem głównym, gdzie strukturę modyfikuje albo program aktualizujący albo aplikacja główna.

pozdrawiam,
Przemek O.

On Sun, 4 Feb 2018 23:46:30 -0800 (PST), immo wrote:

> W dniu piątek, 2 lutego 2018 10:56:03 UTC+1 użytkownik jasiek napisał:
>>> 
>>> Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura 
>>> bazy danych jest dostarczona cała w pełnej konfiguracji.
>>> Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie 
>>> używa jakiś tam obiektów w bazie danych.
>>> A że baza ma tabele, które są puste i nieużywane?
> 
>> Ten sposób uniemożliwiasz przebudowę samej bazy danych /a w momencie tworzenia musi być przemyślana do końca/ ja robię to w taki sposób że w bazie jest tabela  która zawiera nr wersji bazy danych i przy każdorazowym otwarciu programu, sprawdzany jest numer bazy danych oraz na moim serwerze czy jest nowy numer. 
> 
> Czegoś nie rozumiem. A co ma jedno do drugiego?
> Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?

Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
nieużywanych, pluginów.

> Kurcze - ja mam tak samo jak wloochacz i nie wyobrażam sobie utrzymania systemu gdzie np. każdy plugin czy dllka mi miesza po bazie danych robiąc swoje aktualizacje struktury.
> Wolę mieć jedną dostarczaną z programem głównym, gdzie strukturę modyfikuje albo program aktualizujący albo aplikacja główna.

Z wpisu wloochacza wynika, że u niego pluginy nic nie modyfikują tylko
korzystają z gotowej bazy.

-- 
pozdrawiam
Roman Tyczka

> Czegoś nie rozumiem. A co ma jedno do drugiego?
> Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?

A gdzie pluginy przechowują swoje specyficzne dane?
Pliki lokalne? Problem z uprawnieniami.
Katalog TMP -> do usunięcia.
Katalog użytkownika -> Co z archiwizacją?

W dniu poniedziałek, 5 lutego 2018 10:21:35 UTC+1 użytkownik Roman Tyczka napisał:

> > Czegoś nie rozumiem. A co ma jedno do drugiego?
> > Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
> 
> Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
> potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
> nieużywanych, pluginów.

Ja to raczej odczytałem, że nic poza aplikacją główną nie modyfikuje bazy danych. I słusznie, bo ciężko zapanować nad sytuacją gdzie wynikowy stan bazy jest zależny od wielu elementów które mogą go modyfikować.

Jeśli jednak nie mam racji i wloochacz potwierdzi że pracuje tylko z bazą zaprojektowaną od samego początku, to chylę czoła :) Ja nie potrafię przewidzieć rozwoju aplikacji na kilka lat do przodu. Albo inaczej - dla siebie to może i potrafię, ale nie mam tak bujnej wyobraźni, żeby przewidzieć co naszemu ustawodawcy strzeli do głowy w danym momencie :)

> Z wpisu wloochacza wynika, że u niego pluginy nic nie modyfikują tylko
> korzystają z gotowej bazy.

No i słusznie. U mnie tez nie modyfikują. Struktura bazy jest utrzymywana przez aplikację główną lub jej moduł zajmujący się aktualizacjami. Same pluginy czy dllki używają tego co dostarcza core systemu. I tak jak pisał wloochacz, najwyżej są w bazie tabele, procki czy cokolwiek, które nie są używane jeśli nie jest zainstalowany czy dostępny dany plugin/dllka.

pozdrawiam,
Przemek O.

W dniu poniedziałek, 5 lutego 2018 11:31:24 UTC+1 użytkownik kons...@wp.pl napisał:
> > Czegoś nie rozumiem. A co ma jedno do drugiego?
> > Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
> 

Ale wiesz że te pytania nie mają sensu bo za dużo się domyślamy i za dużo uogólniamy?

Wszystko zależy jak jest zaprojektowana aplikacja, jak jest zaprojektowany system pluginów itd itp.

> A gdzie pluginy przechowują swoje specyficzne dane?

Jeśli zaprojektowane przez producenta apki, to w bazie która ma już obsługę tego plugina.

> Pliki lokalne? Problem z uprawnieniami.

ee?? Co? Moim skromnym zdaniem problem z uprawnieniami mają aplikacje źle napisane/zaprojektowane/ lub przeniesione żywcem z ery XP, które to miało w głębokim poważaniu uprawnienia jakiekolwiek.

> Katalog TMP -> do usunięcia.
> Katalog użytkownika -> Co z archiwizacją?

Poza tym to wszystko zależy. :) Może być i TMP lub i katalog użytkownika jeśli taka jest potrzeba lub wymaganie.

pozdrawiam,
Przemek O.

W dniu 2018-02-05 o 10:21, Roman Tyczka pisze:
> On Sun, 4 Feb 2018 23:46:30 -0800 (PST), immo wrote:
> 
>> W dniu piątek, 2 lutego 2018 10:56:03 UTC+1 użytkownik jasiek napisał:
>>>>
>>>> Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura
>>>> bazy danych jest dostarczona cała w pełnej konfiguracji.
>>>> Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie
>>>> używa jakiś tam obiektów w bazie danych.
>>>> A że baza ma tabele, które są puste i nieużywane?
>>
>>> Ten sposób uniemożliwiasz przebudowę samej bazy danych 
No popatrz, to jakim cudem robię to od lat?

> /a w momencie tworzenia musi być przemyślana do końca/ 
No warto pewne rzeczy przemyśleć :)

> ja robię to w taki sposób że w bazie jest tabela  która zawiera nr wersji bazy danych i przy każdorazowym otwarciu programu, sprawdzany jest numer bazy danych oraz na moim serwerze czy jest nowy numer.
Mam podobnie, ale nie widzę związku.

>> Czegoś nie rozumiem. A co ma jedno do drugiego?
>> Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
> 
> Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
> potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
> nieużywanych, pluginów.
Ja tak napisałem?
A gdzie?

>> Kurcze - ja mam tak samo jak wloochacz i nie wyobrażam sobie utrzymania systemu gdzie np. każdy plugin czy dllka mi miesza po bazie danych robiąc swoje aktualizacje struktury.
>> Wolę mieć jedną dostarczaną z programem głównym, gdzie strukturę modyfikuje albo program aktualizujący albo aplikacja główna.
> 
> Z wpisu wloochacza wynika, że u niego pluginy nic nie modyfikują tylko
> korzystają z gotowej bazy.
Każda nowa wersja systemu to najczęściej również zmiany w bazie.
A więc nie ma tak dobrze, że baza jest jedna od początku do końca życia 
aplikacji...

A samo zarządzanie wersjami, tu z kolei inna historia...

Poza tym u mnie plugin, to chyba nie to samo co u Ciebie plugin...
Ja nie mam obcych pluginów.
Dla mnie plugin to wydzielona logiczna część kodu odpowiedzialna za coś.

Jeden plugin może wymagać innego, albo jeden zmienia 
charakterystykę/logikę innego.

-- 
wloochacz

W dniu 2018-02-05 o 11:31, konsul41@wp.pl pisze:
> 
>> Czegoś nie rozumiem. A co ma jedno do drugiego?
>> Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
> 
> A gdzie pluginy przechowują swoje specyficzne dane?
W GPLu, czyli General Persistance Layer.
To nasz (a konkretnie - Viriona i mój) autorski wymysł.

> Pliki lokalne? Problem z uprawnieniami.
GPL posiada dwa media w których przechowuje dane - pliki lokalne i baza 
danych, które są łączone w jedną logiczną hierarchiczną strukturę danych.
Z punktu widzenia używania GPL nie ma znaczenia czy dany węzeł GPL 
pochodzi z pliku czy z bazy danych - interfejs sjest identyczny. Sam GPL 
z kolei nie ma pojęcia o tym, jakie dane i dla kogo serwuje. On 
posługuje się strumieniem danych i lokalizacją w hierarchii (powiedzmy 
ze coś jak XPath).
Kod, który go używa sam musi zadbać o odczyt i zapis danych ze strumienia.
I nie nie ma problemów z uprawnieniami, ponieważ w pliku jest zapisana 
startowa konfiguracja aplikacji, czyli np. jakie pluginu są ładowane i 
jakie zdefiniowano zależności są pomiędzy nimi.

Poza tym uprawnienia...
Są możliwe do nadania do węzłów GPLa, ale prawie nie używam tego, 
ponieważ mechanizm uprawnień u mnie działa całkowicie osobno od wszystkiego.
To znaczy, że np. akcja, okno, czy plugin nie ma pojęcia o uprawnieniach.
Plugin uprawnień, jeśli jest załadowany, wpycha swoje brudny paluchy 
tam, aby dana akcja, okno czy co tam innego nie dało się uruchomić jeśli 
uprawnienia dla aktora są niedostępne czy zabronione.

> Katalog TMP -> do usunięcia.
Dane konfiguracyjne w katalogu tmp?
Hmm...

> Katalog użytkownika -> Co z archiwizacją?
Jak pisałem, w plikacj zapisuję konfigurację aplikacji, a nie dane 
aplikacji.

-- 
wloochacz

W dniu poniedziałek, 5 lutego 2018 16:18:37 UTC+1 użytkownik wloochacz napisał:
> > Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
> > potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
> > nieużywanych, pluginów.
> Ja tak napisałem?
> A gdzie?

Dobra - nie Ty, to był wniosek użytkownika Roman Tyczka, a ja po prostu zanotowałem że to Ty napisałeś :)

Ale w końcu jak? Pluginy Ci grzebią w strukturze bazy czy nie? :)

> Poza tym u mnie plugin, to chyba nie to samo co u Ciebie plugin...
> Ja nie mam obcych pluginów.
> Dla mnie plugin to wydzielona logiczna część kodu odpowiedzialna za coś.

No ja mam tak samo :) Tylko za nic nie mogę zrozumieć jak to jest u pytającego i całej reszty. Bo skoro to są własne pluginy (jak zwał tak zwał) to tym bardziej nie widzę potrzeby wykonywania przez nie jakichkolwiek modyfikacji struktury bazy. 

> Jeden plugin może wymagać innego, albo jeden zmienia 
> charakterystykę/logikę innego.

Pewno tak, ja nie mam zależności pomiędzy pluginami, każdy realizuje coś tam skończonego. Tylko w obrębie logiki tudzież dodatkowej funkcjonalności przez niego dostarczanej.

pozdrawiam,
Przemek O.

On Mon, 5 Feb 2018 16:18:35 +0100, wloochacz wrote:

>> Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
>> potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
>> nieużywanych, pluginów.
> Ja tak napisałem?
> A gdzie?
> 
>>> Kurcze - ja mam tak samo jak wloochacz i nie wyobrażam sobie utrzymania systemu gdzie np. każdy plugin czy dllka mi miesza po bazie danych robiąc swoje aktualizacje struktury.
>>> Wolę mieć jedną dostarczaną z programem głównym, gdzie strukturę modyfikuje albo program aktualizujący albo aplikacja główna.
>> 
>> Z wpisu wloochacza wynika, że u niego pluginy nic nie modyfikują tylko
>> korzystają z gotowej bazy.
> Każda nowa wersja systemu to najczęściej również zmiany w bazie.
> A więc nie ma tak dobrze, że baza jest jedna od początku do końca życia 
> aplikacji...
> 
> A samo zarządzanie wersjami, tu z kolei inna historia...

Ok, nie napisałeś tego wprost i źle to zrozumiałem. Zatem powstaje pytanie,
bo od tego poszło, jak robisz update struktury bazy? Masz jakieś skrypty?
Narzędzia? Kodem to robisz?

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-02-05 o 11:38, immo pisze:
> W dniu poniedziałek, 5 lutego 2018 10:21:35 UTC+1 użytkownik Roman Tyczka napisał:
> 
>>> Czegoś nie rozumiem. A co ma jedno do drugiego?
>>> Dostarczanie pełnej bazy do jej aktualizacji i przebudowy?
>>
>> Ale wloochacz napisał, że jego baza ma od razu pełną strukturę czyli nie
>> potrzebuje aktualizacji, a ma już obiekty bazowe dla wszystkich, nawet
>> nieużywanych, pluginów.
> 
> Ja to raczej odczytałem, że nic poza aplikacją główną nie modyfikuje bazy danych. I słusznie, bo ciężko zapanować nad sytuacją gdzie wynikowy stan bazy jest zależny od wielu elementów które mogą go modyfikować.
> 
> Jeśli jednak nie mam racji i wloochacz potwierdzi że pracuje tylko z bazą zaprojektowaną od samego początku, to chylę czoła :) Ja nie potrafię przewidzieć rozwoju aplikacji na kilka lat do przodu. Albo inaczej - dla siebie to może i potrafię, ale nie mam tak bujnej wyobraźni, żeby przewidzieć co naszemu ustawodawcy strzeli do głowy w danym momencie :)
> 
>> Z wpisu wloochacza wynika, że u niego pluginy nic nie modyfikują tylko
>> korzystają z gotowej bazy.
> 
> No i słusznie. U mnie tez nie modyfikują. Struktura bazy jest utrzymywana przez aplikację główną lub jej moduł zajmujący się aktualizacjami. Same pluginy czy dllki używają tego co dostarcza core systemu. I tak jak pisał wloochacz, najwyżej są w bazie tabele, procki czy cokolwiek, które nie są używane jeśli nie jest zainstalowany czy dostępny dany plugin/dllka.

fuj... Tak teraz mam (kod zastany). Poprzednio struktura bazy była 
nietykalna, wszelkie programy logujące się do bazy otrzymywały 
informację zwrotną, czy mogą, czy nie w zależności od wersji. To nie 
program wyznaczał jak ma wyglądać baza, a baza, jaki program do niej 
może się dostać.. Inaczej informacja zwrotna gdzie leży aktualny moduł, 
by zaktualizować sobie plugin/program/cokolwiek. Od tego by baza była 
spójna jest administrator, który otrzymywał odpwoiedni "instalator" ze 
skryptami modyfikującymi. Teraz zastałem właśnie koszmarek, w którym 
ktos trzyma strukturę w programie i aktualizuje bazę... Więcej z tym 
problemów niż zysku...

Pomysł  głupi, pierwszy raz się z nim spotkałem właśnie rok temu (przy 
prawie 20 latach programowania) i mam nadzieję,  że nigdy więcej....


-- 
http://kaczus.ppa.pl

W dniu 2018-02-12 o 08:33, Tomasz Kaczanowski pisze:
>> No i słusznie. U mnie tez nie modyfikują. Struktura bazy jest 
>> utrzymywana przez aplikację główną lub jej moduł zajmujący się 
>> aktualizacjami. Same pluginy czy dllki używają tego co dostarcza core 
>> systemu. I tak jak pisał wloochacz, najwyżej są w bazie tabele, procki 
>> czy cokolwiek, które nie są używane jeśli nie jest zainstalowany czy 
>> dostępny dany plugin/dllka.
> 
> fuj... Tak teraz mam (kod zastany). Poprzednio struktura bazy była 
> nietykalna, wszelkie programy logujące się do bazy otrzymywały 
> informację zwrotną, czy mogą, czy nie w zależności od wersji. 
Zaraz, STOP!
Jakie programy?
Nikt tu z nas nie pisał o programach, tylko o pluginach.
Plugin != program.

> To nie 
> program wyznaczał jak ma wyglądać baza, a baza, jaki program do niej 
> może się dostać.. Inaczej informacja zwrotna gdzie leży aktualny moduł, 
> by zaktualizować sobie plugin/program/cokolwiek. 
Nic z tego nie rozumiem...

> Od tego by baza była 
> spójna jest administrator, który otrzymywał odpwoiedni "instalator" ze 
> skryptami modyfikującymi. Teraz zastałem właśnie koszmarek, w którym 
> ktos trzyma strukturę w programie i aktualizuje bazę... Więcej z tym 
> problemów niż zysku...
Aje jak trzyma "strukturę w programie"?
Jeśli to podejście ORMowe w stylu code-first, to OK.
Jeśli to skrypty SQLowe w aplikacji, to.. hmm... nie wiem jak współczuć :D

> Pomysł  głupi, pierwszy raz się z nim spotkałem właśnie rok temu (przy 
> prawie 20 latach programowania) i mam nadzieję,  że nigdy więcej....
Nie wiem dokładnie co jest głupim pomysłem wg Ciebie.

Ale z tego co piszesz (jedna baza wiele "programów", które z niej 
korzystają, a każdy uj wie w jakiej wersji) to brzmi jakby ktoś użył 
centralnej bazy danych jak serwera aplikacyjnego, bez wersjonowania API 
tego serwera.
I to faktycznie, pomysł nie tyle głupi, co tego kto to wymyślił i tego 
co się na to zgodził, należałoby publicznie wychłostać.

-- 
wloochacz

W dniu 2018-02-12 o 19:30, wloochacz pisze:

>> Pomysł  głupi, pierwszy raz się z nim spotkałem właśnie rok temu (przy 
>> prawie 20 latach programowania) i mam nadzieję,  że nigdy więcej....
> Nie wiem dokładnie co jest głupim pomysłem wg Ciebie.
> 
> Ale z tego co piszesz (jedna baza wiele "programów", które z niej 
> korzystają, a każdy uj wie w jakiej wersji) to brzmi jakby ktoś użył 
> centralnej bazy danych jak serwera aplikacyjnego, bez wersjonowania API 
> tego serwera.
> I to faktycznie, pomysł nie tyle głupi, co tego kto to wymyślił i tego 
> co się na to zgodził, należałoby publicznie wychłostać.
> 

Jest jeszcze gożej, bo każdy program modyfikuje strukturę bazy wg 
własnego widzimisie... Wersjonowanie  bazy za pomocą daty, więc 
wystarczy, e 2 różne programy będą miały nowsze, ale niespójne struktury 
i burdel jak się patrzy...

-- 
http://kaczus.ppa.pl