Dzisiaj podamy przykłady zapytań SQL przydatnych gdy nie mamy możliwości skorzystania z PHPMyadmina i musimy poprzez komendy SQL zarządzać kodowaniem bazy danych MySQL. Poniżej lista przydatnych naszym zdaniem komend:

1) Sprawdzenie kodowania bazy danych

W pierwszej kolejności wybieramy naszą bazę danych poprzez USE DATABASE_NAME; następnie możemy skorzystać z dwóch komend:

- SHOW VARIABLES LIKE “character_set_database”;

- SHOW VARIABLES LIKE “collation_database”;

Jeżeli wyniki nas nie usatysfakcjonowały będziemy za pewne chcieli zmienić kodowanie. Robimy to przy pomocy komendy:

2) ALTER DATABASE database_name CHARACTER SET utf8 COLLATE utf8_general_ci;

Jeżeli nie wiemy jakie opcje wpisać w kodowaniu możemy dodatkowo sprawdzić obsługiwane przez bazę danych kodowania, wołając komendę:

3)  SHOW COLLATION;

Ponieważ mamy ostatnio okazję popracować z MagentoAPI postanowiliśmy również zamieścić kilka przydatnych informacji na ten temat.

Zaczynamy od podania dostępnych filtrów, które można wykorzystać filtrując dane z API:

Jako że na stronie dokumentacji API nie ma podanych tych informacji z całą pewnością sami również będziemy tutaj często zaglądać.

Przykład wykorzystania:

$server->call($sessionID, 'customer.list', array(array('email' => array('like' => 'jim%'))));

Robiąc modyfikacje i aktualizacje bazy danych przywykłem do wykorzystywania app/console doctrine:schema:update –force

Jak się okazuje istnieje inne lepsze rozwiązanie tzn zastosowanie migracji:

• Po zmianie schema i wygenerowaniu nowych entities wykonujemy polecenie app/console doctrine:migrations:diff –env=nasze_env
• W efekcie zostaje wygenerowany plik migracji w katalogu app/DoctrineMigrations
• wgranie różnic należy wykonać poprzez polecenie app/console doctrine:migrations:migrate –env=nasze_env

I to wszystko , mam dzięki temu uaktualnioną strukturę tylko ostatnio zmienionej tabeli.

W trakcie programowania systemów wykorzystujących bazę MongoDB, warto wspierać się poprzez testowanie zapisu i odczytu informacji poprzez konsolę.

Aby połączyć się do serwera tej bazy danych wykonujemy polecenie: /usr/bin/mongo 127.0.0.1:27017/nazwa_bazy_danych

które połączy nas do wskazanej bazy danych, a tam np możemy już wyszukiwać elementy poprze polecenie : db.collection_name.find();

Możemy również zapoznać się z całym szeregiem innych metod do wywołania poprzez polecenie help() np: db.help()

Tablice asocjacyjne w javascript różnią się znacząco od tablic liczbowych. Największą różnicę odczujemy w momencie gdy chcemy sprawdzić długość tablicy asocjacyjnej. Okaże się wtedy, że wywołanie:

alert(nazwa_tablicy.length);

zwróci wartość 0 niezależnie od tego ile elementów tablicy zdefiniowaliśmy.

Wywołanie typeof(nazwa_tablicy) na tablicy asocjacyjnej zwróci wartość ‘object’. Tablica asocjacyjna jest więc w javascript obiektem.

Jak zatem sprawdzić ilość elementów w tablicy asocjacyjnej.

Wystarczy wywołać następujący kod:

Object.keys(nazwa_tablicy).length

W efekcie otrzymamy ilość elementów tablicy.

Programując w javascript bardzo często zachodzi sprawdzenia czy zmienna której chcemy użyć została już zdefiniowana.

Ponieważ na stronach internetowych i forach bardzo często podaje się dużo różnych, nazwijmy to średnio skutecznych rozwiązań – podajemy jedyne skuteczne i prawidłowe.

if(typeof(nazwa_zmiennej)!=’undefined’){

alert(’zmienna nie została zdefiniowana’);

}

Jak widać nie porównujemy samej zmiennej a jedynie jej typ. Jeżeli zmienna nie została zdefiniowana zawsze otrzymamy typ ‘undefined’. Jeżeli zostanie zdefiniowana zawsze będzie to jedna z wartości:

• number
• string
• boolean
• object
• function

W ramach ciekawostki : typeof ( typeof ( nazwa_zmiennej ) ) zawsze zwróci typ string.

Kolejny wpis z szybką poradą. Zastanawialiście się kiedyś jak pobrać informacje na temat obecnego środowiska w ciele akcji?

Oto rozwiązanie:

$this->get(’kernel’)->getEnvironment();

Najpierw pobieramy service kernel  a następnie z niego odczytujemy zmienną środowiska.

Jeżeli próbujesz wykonać make nginx’a wraz z http_push_module w celu wykorzystania do Comet i trafiłeś na problem typu:

Dzisiaj po problemach z prądem przywitała nas niemiła niespodzianka. Serwer jednego z naszych klientów nie podniósł się – jak się okazało wystąpił jakiś problem z ciągłością danych na dyskach i system nie był w stanie się uruchomić.

W takiej sytuacji rozpoczęliśmy oczywiście od poszukiwania rozwiązania w google i znaleźliśmy.

Tak więc jeżeli i Ciebie powita komunikat podobny do:

Starting file system checks :
...
Automatic file system check failed; help!
Oct. 30 20:14:53 init: /bin/sh on /etc/rc terminated abnormally, going to
single user mode

Uruchom po prostu polecenie: fsck -y

Zaczekaj aż fsck naprawi ewentualne błędy a następnie wykonaj reboot.

Prezentujemy kolejny wpis z serii Symfony2. Tym razem rozwiązujemy problem rozróżnienia adresów logowania w przypadku gdy chcemy umożliwić logowanie użytkownikom i administratorowi.

Zwykły użytkownik będzie logował się poprzez adres /login

Administrator będzie logował się poprzez adres /admin/login

Zaczynamy od konfiguracji w pliku security.yml .

Przykładowy plik konfiguracyjny powinien wyglądać w sposób następujący:


firewalls:
admin_login:
pattern: ^/admin/login$
anonymous: ~

login:
pattern: ^/login$
anonymous: ~

admin_secured_area:
pattern: ^/admin
form_login:
check_path: /admin/login_check
login_path: /admin/login
default_target_path: /admin
logout:
path: /admin/logout
target: /admin/login

secured_area:
pattern: ^/
form_login:
check_path: /login_check
login_path: /login
default_target_path: /
logout:
path: /logout
target: /login

access_control:
- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/admin/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/admin, roles: ROLE_ADMIN }
- { path: ^/, roles: ROLE_USER }


W naszym przypadku cały dostęp do strony wymaga podania hasła przez usera mającego uprawnienia użytkownika (ROLE_USER). W przypadku przejścia do panelu administratora wymagane są uprawnienia administratora (ROLE_ADMIN). Omówmy teraz po kolei definicje w pliku konfiguracyjnym.

firewall:admin_login oraz firewall:login definiują adresy wyświetlenia formularza logowania i jednocześnie udostępniają te adresy użytkownikom anonimowym.

admin_secured_area określa definicję adresów w przypadku których wymagane jest logowanie do panelu administracyjnego.

secured_area określa definicję adresów w przypadku których wymagane jest logowanie zwykłego użytkownika.

access_control określa warunki autentyfikacji użytkownika po przejściu przez firewall. Czyli w przypadku adresów logowania użytkownik nie musi posiadać żadnych uprawnień, jednak w przypadku wszystkich adresów rozpoczynających się od /admin musi mieć uprawnienia ROLE_ADMIN, a w przypadku pozostałych adresów ma to być ROLE_USER.

Ok, tyle jeżeli chodzi o konfigurację w security.yml . Teraz kolejna ważna rzecz – routing.

Przechodzimy do naszego pliku z konfiguracją routingu adresów logowania/wylogowania i definiujemy adresy wykorzystane w konfiguracji security.yml. W naszym przypadku plik taki wygląda w sposób następujący:

admin_login_check:
pattern: /admin/login_check
prefix: /admin
admin_login:
pattern: /admin/login
defaults: { _controller: LmSecurityBundle:Security:adminLogin }
admin_logout:
pattern: /admin/logout
prefix: /admin

login:
pattern: /login
defaults: { _controller: LmSecurityBundle:Security:login }
login_check:
pattern: /login_check
logout:
pattern: /logout

Definicje wyglądają w obu przypadkach w sposób podstawowy. Na wyróżnienie zasługuje zastosowanie definicji prefix. Jest ona tutaj kluczowa, ponieważ pomaga Symfony w przekierowaniu /admin/login_check na /login_check i umożliwia poprawne zalogowanie.

I to w zasadzie wszystko, z tymi informacjami można w sposób swobodny wybudować podział dostępu pomiędzy backend i frontend ( w definicji starego symfony 1.* )