2008-12-11 upgrade

by Vasil Kolev

Upgrade-нах се. Отне около два часа port-ване на мазаниците, дето бях си написал за старата версия (някакво омазано 2.3.2). Може да си свалите diff-а за 2.7 и да се ужасявате на бозите, които съм писал (има и една промяна по базата данни, трябва да се добави колона ‘language’ varchar(2) на wp_posts).

Може даже да отделя малко време за един hack да може да се ползва postgresql база за wordpress най-накрая, никога не съм харесвал mysql…

Tags:

13 Responses to “2008-12-11 upgrade”

  1. LordDoskias Says:

    Никога не съм гледал/ползвал WP, но нямат ли някаква абстракция на DB Layer и всичкото, което трябва да направи човек е да бутне някаква променлива и да може да си ползва Postgre? 2009 сме вече…

  2. Vasil Kolev Says:

    @LordDoskias, имат клас, имат абстракция, обаче има някои неща, които трябва да се пипнат, понеже са mysql specific. Другия проблем според Ники Бачийски е, че няма кой да го поддържа после (а те самите не виждат чак такъв смисъл).

  3. Michel Says:

    Ако MySQL не е хубаво, защо е по-разпространено от Postgre базите данни??… (сорри ако въпросът ми звучи тъпо) :-)

    С WP съм от версия 2.0.5 та до 2.7, и май не съм имал грижи с MySQL базата данни. Е, естествено и че не пипам вътре (защото не разбирам), но… it just works? :-)

  4. Acnapyx Says:

    @Michel: Така, както аз го виждам, просто има хора, които са привърженици на определен тип бази данни, и обичат да водят ‘религиозни войни’ по въпроса. Аз самият не съм се занимавал да пускам бенчмаркове на СУБД, но съм ползвал и двете в битността си на админ; по мои не особено репрезентативни впечатления разликите в производителността на масов сървър (стига да не говорим за десетки хиляди заявки) при употребата на Postgre не е толкова сериозна, че да оправдава пренаписването на коляно на нещо вече достатъчно изтествано (разбирай final версията на WordPress). Е, ако сайтът ти се радва на достатъчно много посещения, тогава реално ще те е грижа… но пък тогава имаш достатъчно програмисти подръка, които да юрнеш да го правят.

    Иначе едно простичко търсене в Google с ключови думи postgres vs mysql разкрива достатъчно flame wars за години занапред. Повтарям, не съм специалист в областта, нито програмист. По мои впечатления Postgre е малко по-бърз, но аз все пак предпочитам да използвам неща ‘out-of-the-box’ без дълбочинни модификации. Повърхностни tweak-ове, добавящи функционалност – моля, но да сменям типа база? Е, ако на някой му се занимава… и пусне официален порт, че и го поддържа… както се поддържа официалният WordPress…

    То впрочем аз май не съм страна по дискусията, щото аз отдавна убих каквото имах върху WordPress и прехвърлих грижите за хостването на блога ми на Сергей и Лари :D Останалите сайтове, за които се грижа, са на супер-доморасли платформи и просто няма да ги коментирам. Оставям ги на съвестта на колегите, които са ги писали в тъмна нощ с левия крак :))))

  5. Канев Says:

    @Michel
    MySQL дължи доста голяма част от популярността си на PHP. Истинската загадка е защо PHP е толкова популярно;) По добре да си остане загатната тази загадка, че виж предишния пост в този блог.

  6. Георги Says:

    Само една малка забележка – линковете за предишен и следващ постинг горе сочат към грешни id-та и съответно не действат коректно.

  7. Vasil Kolev Says:

    @Георги, те и преди не работеха :) Ще се погрижа и за тях.

    @Аспарух, разликата е в издръжливостта на базата. Хвани един mysql, пусни заявки и му ритни тока и гледай сеир… На postgres-а тоя номер можеш да го правиш колкото си искаш, без да се получи някакъв data corruption. Също така като възможности postgres-а е бая по-напред и доста по-близо до стандартите :)
    (а и всеки, който си е играл с mysql го е виждал как убийствено се троши)

  8. martin Says:

    И аз не харесвам нито PhP нито MySql, но не може да се отрече – мнозинството от най-натоварените сайтове ползват PhP, а още повече MySql – просто към момента най-скалируемо. Колкото до обикновения потребител – по-лесно за използване. Не всички обичат конзолата и сложните инсталации, конфигурации и хакове.

  9. teh Says:

    Производителността е доста относителна и субективна и може да се изкара и едното и другото по-бързо … спора прилича малко на такъв за файлови системи ;-)

    PostgreSQL наистина има повече features и е по-близък до стандарта. От 8.3 насам се твърди също, че е и много по-бърз. Но пък тези advanced features обикновено могат да се ползавт само в малък до средно голям проект. В големите проекти такива операции се изместват на друг слой (с повече код в PHP например, или друг междинен слой), защото ако се правят в базата стават много скъпи от към ресурси и трудно скалируеми. MySQL пък от своя страна е по-разпространен по една или друга причина и за него има повече support от колкото за PostgreSQL.

    Това за чупещия се MySQL до някъде е вярно, просто защото по подразбиране се ползва не-журналния стар storage engine MyISAM. От друга страна от хората които се занимават по-сериозно с MySQL почти никой не го ползва, а ползва InnoDB. Държанието на InnoDB е същото като на единствения storage engine на PostgreSQL. И двата обаче могат се счупят, просто е по-трудно, но не и невъзможно ;-)

    Та по тоя случай и според мен /my/pg/-sql спора е безмислен, защото повечето хора познават и се занимават повече с единия от двата продукта и си държат на него и си го защитават. Просто така живота им е по-лесен и това е нормално.

    btw, mysql_real_escape_string() е правилната функция.

    п.с.
    полезни връзки, където хора с опит споделят предимно читави технически мнения и виждания:

    http://www.mysqlperformanceblog.com/
    http://highscalability.com/

  10. Vasil Kolev Says:

    @teh, по-скоро в голям проект тия feature-и са по-лесни да се сипят в базата, по-близо до данните. Требе да хвана червото да разкаже за базата данни на летище София например (дето има един бая голям проект).

    Иначе при нещата, които ние сме правили с pgsql и с mysql, определено postgres-а дава по-добри възможности, особено по темата referential integrity. Ей-сега погледнах manual-а, ами например при alter table не проверява дали няма да се поебе някой constraint, да не говорим, че нормалните check-ове трябва да ги пишеш с trigger-и . Explain-а в mysql ВСЕ ОЩЕ е същия непоносим shit (тоя на pgsql е по-добър, ама пак не съвсем ясен за несвикнали) и т.н., и т.н…

    Това не пречи да се ползва и mysql за някои неща, за един проект например има сериозен шанс да пуснем един mysql cluster (тоя, дето висеше в паметта) и зад него да стои postges като storage за persistent данните (ако memcached не ни хареса достатъчно). Въпрос на case :)

  11. teh Says:

    memcached за persistent storage? или аз нещо не чета изречението правилно? ;-) Него обикновено го слагат преди базата и четат само от него, пишат в него и в базата едновременно или пишат в него и отложено в базата … нали е много бърз и му е евтин ресурса. Пък някаква релационна базата отзад вече за persistent storage (не, че не се мяркат коментари в мейлинг листа им за ползването му и като краен persistent storage с чести бекъпи, но това е идиотско решение и много зависи какво ще държиш вътре) Та тогава има повече логика и екшън в кода който чете нещата а пък базата отзад вижда само прости писания. Това имах предвид в предния коментар с изнасянето на features в по-преден слой.

  12. Vasil Kolev Says:

    @teh, postgres за persistent и отпреде или memcached, или mysql cluster исках да кажа.

    Иначе – поне според мене е по-добре организационната логика и тая, която пази консистентността, да стоят в базата, а отпред да стоят неща като визуализация например, т.е. тези, които са някакси зависими.

    Абе – зависи от случая в крайна сметка. Ти що не идваш по бирите, там е по-интересно да се дъвчат тия неща :)

  13. Alex Stanev Says:

    Като дългогодишно вирял в Oracle света също ще кажа +1 за PostgreSQL. Свикнал съм да използвам пълните възможности на базата и когато се оглеждах за алтернатива Postgre-то се оказа на доста добро ниво. Разбира се, има още доста да се желае, но пък който има зор – да хваща клавиатурата :)

Leave a Reply