SQLite MySql szinkron
2014-02-19T09:58:41+01:00
2014-02-19T13:16:03+01:00
2022-07-22T23:43:56+02:00
  • És ha kifagy, akkor miért jobb, hogy van 1 átmeneti mező?

    "Ilyen mobilkütyükre ne bízd az alkalmazásodat..."

    Ebben egyetértünk, a szerver a mérvadó. Ha az adatok felszinkronizálódtak, akkor OK, ha nem sikerült, és kliens oldalon minden összeomlott pl. egy plutóniumfelhő miatt, akkor úgyis mindegy...
    Mutasd a teljes hozzászólást!
  • Majd megtudod, amikor az elsö androidod kifagy frissítés közben és rollback ide vagy oda, a fene se tudja, mi merre hány méter ...

    Ilyen mobilkütyükre ne bízd az alkalmazásodat - mármint én biztosítom magam, ahol csak lehet.
    Mutasd a teljes hozzászólást!
  • Minek ez az átmeneti dolog? Van ID-je kliens oldalon, és van ID-je szerver oldalon is... ez a kettő bőven elég. A szerver oldali új auto_increment ID-t pedig elkéri beszúrás után (mysql: last insert id).
    Mutasd a teljes hozzászólást!
  • Hali!

    Én átmeneti mezőkkel szoktam megoldani. Ha nem érhető el a szerver, a melót meg még is el kell intézni, akkor egyszerűen adsz egy plusz mezőt a kliensnek is, szervernek is, ami egy atmeneti érték. Kliensen rögzítésnél mondjuk: CONCAT(RANDOM(KELLOSZAM)+1, CliensAzon, DateTime(Now)).
    Tárolod a feladatokat. Eljön a pillanat, amikor szinkronizálsz. Szerverve áttolod az új, eleddig kliensen tárolt adatokat, méghozzá az átmeneti értéket is átviszed, mintha az lenne az id. Majd a szerveren lévő rekord kap egy auto_inc értéket. Ezt visszaírhatod a kliensre egy SELECT ID FROM szervertabla WHERE atmenetimezo = 'atmeneti ertek'...
    Mutasd a teljes hozzászólást!
  • Nem tudom mióta és mennyire használják, illetve mennyire robosztus, de ha van lehetőség adatbázis szerkezet módosításra akkor esetleg megfontolhatnád a GUID használatát, erre a problémára mindenképpen megoldást adna.

    Másik megoldás, hogy magát a szinkronizálás eljárást módosítod és úgy kezeled, mintha a szerveren történne új ügyfél felvétel. Írsz egy scriptet, ami kiolvassa az androidon a változtatásokat, beszúrja az új ügyfelet és a többi beszúrásnál/módosításnál ezt az új azonosítót használod.
    Mutasd a teljes hozzászólást!
  • Akkor XML példában, ahogy én elképzeltem (csak az ügyfél adatokra):
    - Új ügyfél rögzítése kliensen
    - Szinkronizálás (kimenő xml):

    <request param="..."> <ugyfelek> <ugyfel serverID=""> ... </ugyfel> </ugyfelek> </request>
    - Szerver dolgozik...
    - Szerver válasz pl:

    <response code="..."> <ugyfelek> <ugyfel serverID="128"/> </ugyfelek> </response>

    Már meglévő (korábban már volt szinkronizálva) ügyfél adatok küldése szerver felé pl:

    <request param="..."> <ugyfelek> <ugyfel serverID="256"> ... </ugyfel> </ugyfelek> </request>



    Kliens oldalon (sqlite) nem kell PK módosítás, csak 1 + mező (a példában serverID), hogy mi az ID-je szerver oldalon.
    Mutasd a teljes hozzászólást!
  • Eddigi terveim alapján igen. Küldhetek végülis json-t is, de úgy sem érzem sokkal egyszerűbbnek a dolgot (ez xml, de olvashatóbb most):

    <ugyfel> <nev>XY</nev> <cim> <zip>4030</zip> </cim> </ugyfel>

    Válaszban akkor is küldenem kell, hogy ennek mi lett az id-je a szerveren, eszerint módosítani sqliteban. Ha ott PK-módosítás miatt ütközés lenne, akkor csak görgeti a problémákat...

    Az lehet még járható út, hogy sqliteban más a PK mező mint mysqlben...
    Mutasd a teljes hozzászólást!
  • Te az SQL stringet küldöd fel?
    Mutasd a teljes hozzászólást!
  • > mi a gond, mit kell módosítani a queryben?
    SQLite oldalon:

    INSERT INTO ugyfelek (Nev,...) VALUES ("XY",...);
    Ebből kapok egy ugyfel_id-t, egyszerűség kedvéért 1.

    INSERT INTO cimek (UgyfelID,Zip,...) VALUES (1,4030,...);
    Ezeket felküldöm szerverre, első lefut, második már "hibát okozna", mert közben mysqlben jött létre "1"-es ugyfel_id. Szóval a 2. queryt már úgy kell futtatnom, hogy közben az "1"-et lecserélem a köv. autoincrement id-re, legyen ez "2"?
    Aztán válaszban leküldöm az androidnak, hogy az ottani 1-es ugyfel az már nem 1-es, hanem 2-es, és hogy közben létrejött az 1-es is szerveren, és hogy erről is tudjon az app...
    Ha jól írom meg és van tranzakciókezelés, nem lehet hiba, de így sok munka és sok tesztelést igényel...
    Mutasd a teljes hozzászólást!
  • A kulcsaid szinkronban tartása sem lesz könnyebb szerintem... én továbbra is úgy gondolom, hogy a szerver a mérvadó, az sqlite ID-k pedig csak lokálisan kellenek az egyes klienseknél. A kliensenként eltérő PK offsetekkel is sok baj lehet, nem is beszélve arról, ha egyszer csak bejön még 1 androidos eszköz a képbe. Szóval én továbbra is a szerver ID-ket visszaszinkronizálnám a kliensre (a lokális ID-k mellé)...
    A szerver oldali insertekkel (kliens adatok alapján) pedig nem igazán értem, hogy mi a gond, mit kell módosítani a queryben? Tranzakciót nyitsz -> elvégzel minden insertet -> commitolsz (vagy hiba esetén rollback) -> response-ban a protokollod szerint visszatolod a keletkező ID-ket.
    Mutasd a teljes hozzászólást!
  • Az update és delete műveletekkel és azonosításukkal nincs gond.
    Inserttel az a gond, hogy ha rögzítenek egy ügyfelet az appban, és hozzá címet, meg átvett terméket meg aláírást, stb, akkor az 4-5 insert. Itt ugye van egy ugyfel_id, amit az egyéb adatok insert-je is tartalmaz, amit szerveren beszúrás előtt módosítanom kell a queryben. Ezt problémásnak tartom, ezért gondolkozok olyanban, hogy kizárólag egyedi kulcsokkal dolgozom. Ugye az sqlite-ok között is lehet ütközés, ami szintén kezelendő.
    Mutasd a teljes hozzászólást!
  • Én biztosan nem vegyíteném az auto_increment ID-ket program által kalkulált ID-kkel. Talán leküldeném a kliensnek a szerver oldali ID-t is, ha szinkronizáláskor ezt is visszaküldi egy rekordhoz, akkor be lehet azonosítani (és mondjuk update), ha nem, akkor új rekordként tekinteni rá (insert).
    Mutasd a teljes hozzászólást!
  • Van egy php-mysql alapú crm rendszerem, amihez most készül natív androidos alkalmazás, aminek offline is működőképesnek kell lennie (a kézbesítést alá kell írnia az ügyfélnek, de vasbeton épületekben nincs mobilnet). Az alkalmazás sqlite adatbázist fog használni adatok tárolására. Szinkronizálás indításakor az app lehúzza a mysql azon részét, ami az adott felhasználóhoz tartozik. Amikor az app újra online lesz, újra szinkronizál (közben adatfeltöltés is történik).
    Probléma: Adatbázisba beszúrás mindkét oldalon történik, ezért az elsődleges kulcsok kezelésére mysql oldalon az auto_increment_increment értékét tervezem 1-ről 10-re módosítani. Ez azt jelenti, hogy mysqlben minden elsődleges kulcs 10-zel osztható lesz.
    Android alkalmazásból max. 9 példány fog egyszerre futni, ezért azt gondoltam, minden android felhasználó kap egy auto_increment_offset-et 1-től 9-ig, így az ők elsődleges kulcsaik 1-re vagy 9-re fog végződni, így gyerekjáték a szinkronizálás.
    Kérdés: mennyire praktikus/szép megoldás, van-e ettől kezelhetőbb/egyszerűbb?
    Mutasd a teljes hozzászólást!
abcd