Hibernate second level cache

A kiindulási persistenceContext.xml, amit megmódosítunk jól, hogy a Hibernate ehcache segítségével kicsit fürgébb legyen:

Tomcat run as user...

Eltelt 365 nap, itt van hát egy újabb note :)

#!/bin/sh
### BEGIN INIT INFO
# Provides:          SCRIPTNAME
# Required-Start:    $local_fs $remote_fs $network $syslog $named
# Required-Stop:     $local_fs $remote_fs $network $syslog $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     true
# Short-Description: Start/stop Tomcat server for SOMETHING
### END INIT INFO

export TOMCAT_HOME=/path/to/tomcat
export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")

case $1 in
  start)
    # Start daemon
    su -c "$TOMCAT_HOME/bin/startup.sh" USERNAME
    ;;

  stop)
    # Stop daemon.
    $TOMCAT_HOME/bin/shutdown.sh
    ;;

  *)
    # usage
    echo "usage: $0 start|stop"
    exit 1
    ;;
esac

Saját Java verziók és azok közti váltás rendszer szinten

Ez csak egy emlékeztető:
http://www.code-complete.com/code/index.php?/archives/46-using-update-alternatives-to-add-additional-java-versions-to-etcalternatives.html

# update-alternatives --install "/usr/bin/java" "java" "/usr/java/default/bin/java" 3
# update-alternatives --install "/usr/bin/javac" "javac" "/usr/java/default/bin/javac" 3
# update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/java/default/bin/javaws" 3

Hibernate, Eclipselink JPA vs stored procedures vs stored functions

Szóval az van (szóval nem kezdünk mondatot! hehe :P), hogy próbára tettem a tárgyban jelölt két JPA implementációt, mit alkotnak, ha tárolt eljárásokkal és/vagy függvényekkel kerülnek szembe. Próbáltam védeni a becsületüket, de nem sikerült teljes mértékben.

Exim turbózása tárolt eljárások... helyett UDF azaz User DefinedFunction-el :)

Egy projekt kapcsán feldobták a feladatot: Mikor egy ügyfél felad egy hirdetést, a nyomonkövethetőség okán generáljon hozzá a rendszer egy e-mail címet, és azt jelenítse meg a usernek, majd erre az e-mail címre érkező, majd továbbított levelek száma legyen nyilvántartva, hogy fel tudjunk mutatni egy statisztikát, mennyire volt az sikeres.
Ennek megoldásához a már eleve MySQL alapokon működő eximünket módosítottam úgy, hogy a szükséges címek leválogatását rábízza egy UDF-re, egy egyszerű select eredményeképpen megkapjuk a listát, és maga a MySQL intézze el a továbbítások számolását.

Keresés MySQL adatbázisban - ékezetek és html tag-ek, mint zavarótényezők..

Az alap probléma az, hogy a CMS részeként, a megrendelő adminisztrációs felületen, bármilyen tartalmat feltölthet, mivel már ott tart a webes technika ugye, hogy a laikusok kezébe adjuk a wysiwyg editort¹, amivel mintha csak word-ben kalimpálna, klikkelgetős módszerrel formázhatja a szöveget, szúrhat be képet stb. stb...

Ezenkívül magyarok vagyunk, használunk sok szép ékezetet, amiket a MySQL még mindig nem tud túl jól megkülönböztetni. Ezen okokból kifolyólag, mikor az alap keresési módszert használnánk (SELECT content FROM table WHERE content LIKE '%valami%'), akkor számolnunk kell azzal, hogy a "tárogat" és a "tartalom" egyaránt meg fog jelenni, ha pl. a felhasználó arra keresett rá, hogy "tár".

Ez még mindig nem minden, hiszen a wysiwyg editornak köszönhetően, a content tele lesz html kóddal is, így aztán a találatok között lehet olyan content is, melyben nem szerepel ugyan valós tartalomként a "tár", sem pedig a "tar", de lehet, hogy egy link tartalmaz "target" definíciót is. Ez aztán végképp nem kell nekünk mint találat.

¹ pl.: tinyMCE

Beszédes URL-ek .htaccess, mod_rewrite azaz a rewrite engine ereje 1.

Nagyon sokan rá vannak kattanva az úgynevezett "beszédes URL"-ekre, amik kb. ilyenek:

http://blog.rhodeus.hu/2008/01/beszedes-url-ek-htaccess-modrewrite.html

Szimplán csak annyiról van szó, hogy a felhasználó által egyszerűbben megjegyezhető, mintha ugyanez ebben a formában lenne például:

http://blog.rhodeus.hu/?year=2008&month=01&day=14&entryID=28

De leginkább azért ajánlott, mert állítólag a google is jobban szereti, valamiért sokkal jobbak az indexelési statisztikák az előbbi URL-ekre, mint az utóbbiakra. Mindenesetre ebbe a részébe én most nem mennék bele, inkább lássuk, miből áll ez az egész.