Witam,

Dość trudne zadanie mnie czeka. Mamy dość złożony CMS. Co roku musi
powstać z niego kopia archiwalna dostępna publicznie. Póki co nie
przychodzi mi do głowy nic lepszego jak ręczne kopiowanie bazy danych i
plików systemu do podkatalogu. Jeśli to miałoby być istotne dla
dyskusji to mamy PHP i PostgreSQL. Czy macie wypraktykowane lepsze
podejście? Zastanawiałem się nad przestrzeniami nazw w bazie lecz
musiałbym wszelkie zapytania SQL przerabiać tak aby to uwzględniały.
Możliwe ale ostateczne byłoby to podejście.

do góry

Dnia Sat, 25 Dec 2010 22:49:18 +0100, Marek napisał(a):

> podejście? Zastanawiałem się nad przestrzeniami nazw w bazie lecz
> musiałbym wszelkie zapytania SQL przerabiać tak aby to uwzględniały.
> Możliwe ale ostateczne byłoby to podejście.

Jeśli to jest potrzebne raz na rok, to bym się nie bawił w jakąś wielką
filozofię tylko po prostu to kopiował. Pewnie i tak za kilka lat będzie
kolejna rewolucja.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2010-12-26 02:51, Borys Pogoreło pisze:

> Jeśli to jest potrzebne raz na rok, to bym się nie bawił w jakąś wielką
> filozofię tylko po prostu to kopiował. Pewnie i tak za kilka lat będzie
> kolejna rewolucja.

W tym przypadku pewnie tak postąpię. Przypuszczam też, że ciężko będzie
wymyślić coś rozsądniejszego. Jednakże "zaryzykuję" i pozostawię wątek
aktualny. Może się zdarzyć, że w przyszłości taka funkcjonalność będzie
potrzebna.

do góry

W dniu 2010-12-25 22:49, Marek pisze:
> Witam,
>
> Dość trudne zadanie mnie czeka. Mamy dość złożony CMS. Co roku musi
> powstać z niego kopia archiwalna dostępna publicznie. Póki co nie

Co to jest kopia archiwalna? IMHO do tego wystarczy kolumna "status".

artur

do góry

W dniu 2010-12-26 16:08, Artur Muszyński pisze:
>> Dość trudne zadanie mnie czeka. Mamy dość złożony CMS. Co roku musi
>> powstać z niego kopia archiwalna dostępna publicznie. Póki co nie
>
> Co to jest kopia archiwalna? IMHO do tego wystarczy kolumna "status".

Serwis będzie dość złożony. Będzie zawierał m.in. archiwum repertuaru
kinowego oraz imprez + dokumenty towarzyszące (newsy, opisy czegoś tam).
W efekcie tych dokumentów może być całkiem sporo. Co roku ma być
archiwizowany a to oznacza, że w roku 2012 będę mógł oglądać sobie
kalendarium imprez z roku 2010, 2011 plus wszystkie inne strony
archiwalne: np. "informacje o firmie" z roku 2010. O ile kalendarium
dałoby się filtrować przedziałem dat o tyle pozostałe dokumenty zupełnie
nie. Np. Gdy w roku 2011 informacje o firmie będą inne to poprzednia
wersja z 2010 powinna też być dostępna - czyli w menu może być inny URL
do tego dokumentu. Tak więc układ menu może też się zmieniać.

do góry

W dniu 2010-12-26 18:48, Marek pisze:

> O ile kalendarium
> dałoby się filtrować przedziałem dat o tyle pozostałe dokumenty zupełnie
> nie. Np. Gdy w roku 2011 informacje o firmie będą inne to poprzednia
> wersja z 2010 powinna też być dostępna - czyli w menu może być inny URL
> do tego dokumentu. Tak więc układ menu może też się zmieniać.

Myśl pozytywnie. Wersjonowanie bazy nie jest niczym nadzwyczajnym. Układ
menu też, choć to już trochę co innego, dlatego pytałem na początku,
czego ta archiwizacja ma dotyczyć.

artur

do góry

W dniu 2010-12-25 22:49, Marek pisze:
> Witam,
>
> Dość trudne zadanie mnie czeka. Mamy dość złożony CMS. Co roku musi
> powstać z niego kopia archiwalna dostępna publicznie. Póki co nie
> przychodzi mi do głowy nic lepszego jak ręczne kopiowanie bazy danych i
> plików systemu do podkatalogu. Jeśli to miałoby być istotne dla dyskusji
> to mamy PHP i PostgreSQL. Czy macie wypraktykowane lepsze podejście?
> Zastanawiałem się nad przestrzeniami nazw w bazie lecz musiałbym
> wszelkie zapytania SQL przerabiać tak aby to uwzględniały. Możliwe ale
> ostateczne byłoby to podejście.

Szybkie i proste:
- klasa dziedzicząca po tej, która obsługuje Ci stronę,
- podmiana nazw tabeli gdy podany ?year=2007 z moj_content na
moj_content_2007. Cała filozofia.. Pliki analogicznie.



\pozdr,p

do góry

Dnia Tue, 28 Dec 2010 09:24:13 +0100, beherit / pn napisał(a):

> Szybkie i proste:
> - klasa dziedzicząca po tej, która obsługuje Ci stronę,
> - podmiana nazw tabeli gdy podany ?year=2007 z moj_content na
> moj_content_2007. Cała filozofia.. Pliki analogicznie.

Czyli:

a) musimy i tak zduplikować bazę
b) musimy i tak zduplikować pliki, bo ich układ może być różny na
przestrzeni lat
c) musimy stworzyć nowe pliki klas, wprowadzając więcej zamieszania i
siwych włosów gdy przyjdzie do bardziej fundamentalnych zmian w kodzie
d) musimy mieć *cały* system napisany obiektowo (o czym nie było mowy)

Podsumowując - będzie to skopiowanie całości lewą ręką przez prawe ramię
podczas tańca ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

On Tue, 28 Dec 2010 09:59:10 -0000, Borys Pogoreło <b...@p...edu.leszno>
wrote:

>> Szybkie i proste:
>> - klasa dziedzicząca po tej, która obsługuje Ci stronę,
>> - podmiana nazw tabeli gdy podany ?year=2007 z moj_content na
>> moj_content_2007. Cała filozofia.. Pliki analogicznie.
>
> Czyli:
>
> a) musimy i tak zduplikować bazę

Nie. Dodać kolumnę na datę/wersję.

> b) musimy i tak zduplikować pliki, bo ich układ może być różny na
> przestrzeni lat

Nie od razu. Nowe pliki dodawaj pod nową nazwą, jeżeli konieczne jest
zachowanie wyglądu starej strony.

> c) musimy stworzyć nowe pliki klas

WTFBBQ? Nie możesz nowej funkcjonalności dodawać tak, aby była
"kompatybilna wstecz"?

Poza tym w OOP wymyślono pare rzeczy, które mają zastąpić copy&paste...

--
http://pornel.net
this.author = new Geek("porneL");

do góry

Dnia Tue, 28 Dec 2010 13:10:33 -0000, porneL napisał(a):

>> a) musimy i tak zduplikować bazę
>
> Nie. Dodać kolumnę na datę/wersję.

A jeśli w międzyczasie zmienia się struktura bazy? Trochę danych tu,
trochę danych tam. Można by to jakoś łatać logiką na poziomie bazy, ale
jeśli od początku tego tak nie projektowano, to nie chciałbym być osobą
mającą to tak przebudować.

>> b) musimy i tak zduplikować pliki, bo ich układ może być różny na
>> przestrzeni lat
>
> Nie od razu. Nowe pliki dodawaj pod nową nazwą, jeżeli konieczne jest
> zachowanie wyglądu starej strony.

A jeśli zawartość plików się zmienia, a nazwy pozostają? Niekoniecznie
musi to być w tym systemie rozwiązane tak, że zawsze tworzony jest nowy
plik, a zmienia się tylko jakiś wskaźnik.

>> c) musimy stworzyć nowe pliki klas
>
> WTFBBQ? Nie możesz nowej funkcjonalności dodawać tak, aby była
> "kompatybilna wstecz"?

Nie wszystko da się tak dodać.

> Poza tym w OOP wymyślono pare rzeczy, które mają zastąpić copy&paste...

A ja znów przypominam, że nie ma ani słowa o OOP w pierwszym poście :)
Zaś w PHP zbyt wielu z tych rzeczy nie ma...

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry