JavaForum
Space shortcuts
Child pages
  • Adatbázis update webalkalmazás
Skip to end of metadata
Go to start of metadata

Sziasztok!

Adott egy folyamatosan fejlesztett adatbázist használó alkalmazás. A fejlesztés során az adatbázis változik, ezért minden kiadás mellé update scriptek kerülnek kiadásra. Ezek részben sima sql fájlok, részben egy jar ami JPA-n keresztül végzi el a szükséges módosításokat. Nyilván mikor melyik megoldás az egyszerűbb.

A feladat a frissítési folyamat automatizálása. Pl. adatbázis verzió jelenleg 30, fel kell húzni 42-ig. A cél egy olyan webalkalmazás ami tartalmazza a frissítéseket, telepítjük az alkalmazásszerverre és szépen lefuttatja a frissítéseket.

Első megoldás: már létezik ilyen, csak én nem találtam meg

Második megoldás: kell írni egyet. Ebben az esetben az alábbi problémák merültek fel így elsőre:

  • mi a célszerű modul formátum? Simán saját package-be tenni egy-egy updater-t, vagy külön jar-ba
  • mivel a persistence unit folyamatosan változik, hogy kezeljük az egymás után használandó megváltozott persistence unitokat? Saját classloader? Külön nevet mindegyiknek?
  • hova célszerű logolni? Fájlba nyilván kényelmes. Ha viszont el szeretném küldeni a logot automatikusan emailben, akkor azt már kényelmetlen lehet visszaolvasni.

 

Még erősen tervezési szakaszban van a dolog, szóval minden megoldás, ötlet érdekel!

Köszi!

pentike

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

7 Comments

  1. Czimmermann Gábor

    Miért akarjátok Java-ban megoldani? Pl. mi Ruby on Rails migrációkat használunk. De ha jól tudom van már SQL-es megoldás is. Egy plusz script kell, ami az entitásból generálja a migrációs scriptet.

    Ha mindenképp Java, akkor azt javaslom, hogy a migrációs scripteket egy könyvtárba érdemes bemásolni. Ha az alkalmazás lefutatta, akkor egy DB táblába bejegyzi és átrakja a scriptet egy másik könyvtárba.

    Nyilván az input könyvtárhoz nem szabad mindenkinek írási jogot adni!

    A migrációs script olyan formátumú legyen, ami alapján az alkalmazás tudja, hogy JPA, vagy SQL műveletet kell végeznie.

    A Java megoldásnak az is a hátulütője, hogy ha új tábla (Model) lesz, akkor a migrációs programot is cserélni kell, mert a JPA nem ismeri még őket. (Kivéve, ha csak SQL van.)

    És persze a migrációs JPA nem ugyanaz, mint amit egyébként az alkalmazás használ. Így nem kell minden esetben cserélni csak, ha új entitás kerül bele.

    1. Anonymous

      Azért mert egyrészt Weblogic az infrastruktúra, abban mozognak otthonosan az üzemeltetők másrészt így lehet használni az alkalmazás domain modeljét a migrálásoknál, transzformációknál. Nem sanszos, hogy egy eddig nem használt technológiát befogadnak.

      Ezt a másolós dolgot nem igazán értem, de lehet nem jól fogalmaztam meg, hogy egy webalkalmazásnak kell tartalmaznia az update szkripteket/osztályokat.

  2. Czimmermann Gábor

    Így már értem, hogy nehézkes lesz minden. (smile)

    Az egyik megoldás az univerzális migráló osztály, aminek a migrációs scriptjei JPQL, vagy SQL-ek és induláskor megnézi mi a DB verziója és mire kell up-/downgradelni.

    Az SQL/JPQL scriptek a WAR-ban lennének, amit viszonylag könnyű elérni. (Ha JAR-ban van, akkor nehéz kibányászni: WAR->JAR>files)

    A másik, hogy minden deploy az aktuális JPA-t és PU-t tartalmazza, amiben benne vannak az upgrade/downgrade elemek metódus/segédosztály szinten. Szintén induláskor megnézi hol tart és hova kell frissítenie.

    Ha mavennel fordítasz, akkor érdemes külön projektbe rakni ezeket és verziózni.

    Arra kell vigyázni, hogy ha valaki rossz verziót telepít, akkor elrontja a DB-t is. Ezért nem biztos, hogy automatikusan kell futtatni.

     

    1. Péntek Gábor

      Mindenképpen egy alkalmazásba kell az összes update script, hogy lehessen egyszerre több verziót is lépni és ne kelljen egyenként deployolni minden egyes migráló scriptet.

  3. Viczián István

    Flyway nem játszik?

    http://flywaydb.org/

    Van egy feature comparison is.

    1. Péntek Gábor

      Ezt még nem ismertem, megnézem. Köszi!

      Szerk: ígéretesnek tűnik, kipróbálom, bár a JPA domain változásával szerintem lesznek problémák, de legalább az API-t nem kell kitalálni.

      1. Péntek Gábor

        Végülis Flyway lett. Két probléma merült fel vele:

        1. különböző persistence.xml -ek kezelése. Ennek megoldása egy saját contextClassloader lett amit minden egyes migrátor beállít magának:
            private void setPersistenceXmlClasspath(final String classpath) {
                if (classpath == null) {
                    throw new IllegalStateException();
                }
                
                checkClasspathLiteral(classpath);
                Thread.currentThread().setContextClassLoader(new ClassLoader() {
                    final String cp = classpath;
                    @Override
                    public Enumeration<URL> getResources(String name) throws IOException {
                        if (name.equals("META-INF/persistence.xml")) {
                            try {
                                URL resource = getResource(cp + "/persistence.xml");
                                return Collections.enumeration(Arrays.asList(resource.toURI().toURL()));
                            } catch (URISyntaxException e) {
                                // do nothing
                                e.printStackTrace();
                            }
                        }
                        return super.getResources(name);
                    }
                    
                    @Override
                    public InputStream getResourceAsStream(String name) {
                        // TODO Auto-generated method stub
                        return super.getResourceAsStream(name);
                    }
                    
                    @Override
                    public URL getResource(String name) {
                        // TODO Auto-generated method stub
                        return super.getResource(name);
                    }
                });
            }

        2. A JdbcMigrator-ból dobott exception-ök csak egy e.toString() hívással kerülnek a logba, tehát nem látszik honnan jöttek. Erre már van egy feature request a githubon, remélem gyorsan megoldják.

        https://github.com/flyway/flyway/issues/548