Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:dydaktyka:sbd:2009:projekty:skos-ldap:start [2010/02/11 16:10] sbd09 |
pl:dydaktyka:sbd:2009:projekty:skos-ldap:start [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 352: | Linia 352: | ||
| Strony obsługiwane są na porcie 8000, który jest defaultowym portem Django. W przypadku zmiany portu należy zmienić również numery portów w plikach katalogu //template//. | Strony obsługiwane są na porcie 8000, który jest defaultowym portem Django. W przypadku zmiany portu należy zmienić również numery portów w plikach katalogu //template//. | ||
| + | |||
| + | Przed uruchomieniem serwera pamiętać o synchronizacji Django z bazą danych !!! | ||
| + | <code>$ python manage.py syncdb</code> | ||
| Serwer uruchamiany jest za pomocą polecenia: | Serwer uruchamiany jest za pomocą polecenia: | ||
| Linia 419: | Linia 422: | ||
| ===== Problemy jakie wystąpiły w trakcie realizacji projektu, proponowane rozwiązania i kierunki rozwoju ===== | ===== Problemy jakie wystąpiły w trakcie realizacji projektu, proponowane rozwiązania i kierunki rozwoju ===== | ||
| + | - W punkcie pierwszym został już przedstawiony problem kodowania danych. Nie wiemy, czy jest to pewnego rodzaju anomalia związana bezpośrednio z dystrybucją linuxa, na której implementowany był serwer, czy problem ten jest powszechny. Na sieci brak jest informacji na ten temat, ze względu na fakt, iż użycie backendu umożliwiającego dostęp do bazy LDAP za pośrednictwem PostgreSQLa jest rzeczą niezwykle rzadką. Jakkolwiek stworzenie dwóch baz danych wydaje się kłopotliwe uważamy, że mamy całkiem przyzwoite rozwiązanie tego problemu. Nasz pomysł wynika z faktu, iż baza danych pracowników nie notuje dynamicznych, częstych zmian. Również wprowadzone zmiany nie muszą mieć natychmiastowego skutku. Należałoby stworzyć skrypt, którego zadaniem jest aktualizacji tabeli //ldap_persons// w bazie **aghldap**, przechowującej przetworzone na podstawie widoku dane, tak by nie dochodziło do duplikowania informacji. Aktualizacja polegałaby na całkowitym wyczyszczeniu tabeli i ponownym jej uzupełnieniu. Operacja ta zajmuje około 20 – 30 sekund. Następnie skrypt usuwałby zawartość tabeli o tej samej nazwie w bazie **ldap** i kopiował dane z jednej tabeli do drugiej. Operacja aktualizacji bazy danych, na której oparty jest serwer LDAP trwałaby więc bardzo krótko. Skrypt byłby wykonywany nad ranem, każdego dnia za pomocą **crona**. | ||
| + | - Podczas prac nie udało się wyeliminować powtórzeń stanowiących o przynależności obiektu do klas eduPerson oraz pleduPerson. Niektórzy pracownicy, po usunięciu powtarzających się informacji mają przeznaczonych nawet kilka wierszy w tabeli //ldap_persons//. Z niewiadomych nam przyczyn powoduje to nadmierne powtarzanie informacji.\\ {{:pl:dydaktyka:sbd:2009:projekty:skos-ldap:gq_powtorzenia.png|}} | ||
| + | - Numery ID pracowników w tabeli //ldap_person//, a co za tym idzie i w widoku ldap_entries zaczynają się od wartości 1000. Powodem takiego rozwiązania jest fakt, iż ID < 1000 pozostawiliśmy dla obiektów klasy organizationlUnit – tj. jednostki AGH, które można by w przyszłości również scharakteryzować za pomocą atrybutów klas protokołu LDAP i udostępnić dane z nimi związane. | ||
| + | - Dobrym posunięciem byłoby stworzenie nowego schematu z klasami specjalnie dla jednostki jaką jest AGH. W projekcie, przecierając nowe szlaki korzystaliśmy jedynie z powszechnie dostępnych schematów. | ||
| + | - Wyniki wyszukiwania pojawiają się na stronie dopiero po przeszukaniu całej bazy. W przypadku zapytań, których wynikiem jest duży zbiór gromadzenie danych trwa stosunkowo długo. Dobrym pomysłem byłoby wyświetlanie wyników na bieżąco, wykonując przeszukanie fragmentów bazy za każdym razem. Rozwiązałoby to również problem przekroczenia maksymalnego limitu znalezionych rekordów. | ||
| + | - Należałoby również sprawdzić poprawność sparsowanych danych, czy gdzieś nie doszło do poważnych błędów i przekłamań. | ||
| + | - Najpoważniejszy problem pojawił się w przypadku pracowników posiadających dwa miejsca pracy, tzw. główne i dodatkowe miejsce pracy. W systemie SKOS mamy 30 takich pracowników. Powoduje to przypisanie atrybutom związanym z miejscem pracy, a więc //description, l, departmentNumber, roomNumber, eduPersonAffiliation, plPosition// dwóch wartości.\\ Przykład pokazuje tabela:\\ {{:pl:dydaktyka:sbd:2009:projekty:skos-ldap:tragedia.png|}} \\ Podczas testów okazało się, że dodana kolejno wartość atrybutu nie jest wstawiana na koniec listy, ale według porządku alfabetycznego. Sytuacja ta powoduje przemieszanie się ze sobą miejsc pracy, tak że nie można ich odróżnić. Nie udało nam się znaleźć nigdzie, czy można zmienić sposób, w jaki dodawane wartości atrybutów są porządkowane. Jedynym rozwiązaniem byłoby otagowanie wartości związanych z dodatkowym miejscem pracy. Aczkolwiek znacznie zmniejszyłoby to czytelność w przypadku przeglądania bazy za pomocą edytora graficznego, czy też książki adresowej. | ||
| + | ===== Wykaz literatury ===== | ||
| + | - [[http://www.python.org/doc/|www.python.org]] | ||
| + | - [[http://www.easysoft.com/developer/interfaces/odbc/linux.html|www.easysoft.com]] | ||
| + | - [[http://darold.net/projects/ldap_pg/HOWTO/index.html|darold.net]] | ||
| + | - [[http://www.djangobook.com/en/1.0/|www.djangobook.com]] | ||
| + | - [[http://www.oav.net/mirrors/LDAP-ObjectClasses.html|www.oav.net]] | ||
| + | - [[http://projekt-ldap.uci.umk.pl/raporty/ftp/uci/pledu.html|projektldap.uci.umk.pl]] | ||
| + | - [[http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html|middleware.internet2.edu]] | ||
| + | - Adrian Holovaty, Jacob Kaplan-Moss „The definitive guide to django web development done right”, 2nd edition, July 2009 | ||
| + | - Gerald Carter „LDAP system administration”, O'Reilly, March 2003 | ||
