Objektumtárolási réteg - PHP
2010-04-06T01:25:44+02:00
2010-04-10T03:44:49+02:00
2022-07-19T04:22:48+02:00
  • Ahm, én meg találtam hasonló felületű mappert, mint amit te szeretnél.
    Mutasd a teljes hozzászólást!
  • Találtam valamit, ami valami hasonlót csinál, mint amire én gondoltam: RedBean
    Ebben a cuccban is van pár hasonlóság, de ez alapvetően különböző.
    Mutasd a teljes hozzászólást!
  • Köszönöm, bár hallottam már ilyesmiről, azt azért nem mondanám, hogy ismerek ilyen adatbázis-rendszereket. Kár, hogy egy ilyenhez sincs PHP alá API.
    Mutasd a teljes hozzászólást!
  • Nyilván a kapcsolatokon nem fog túlnyúlni a rendszer. Az ő módszerével manuálisan meg lehet oldani a kapcsolatok kezelését, aktív rekorddal meg egy __get-el...
    Mutasd a teljes hozzászólást!
  • Egyébként tudtad, hogy van olyan adatbázis kezelő, mely nem relációs, hanem oo alapú (wiki)? Csak ezek nem annyira elterjedtek és ismertek - egyelőre.
    Mutasd a teljes hozzászólást!
  • A lekérdezést is meg lehetne oldani ugyanúgy:

    $emp=new Employee(); $emp->setName('Pista Kovács'); $tasks=new List('Task'); $oio->get($emp,$tasks);

    A probléma inkább ott kezdődik, amikor mondjuk meg akarsz szakítani egy kapcsolatot. Pl egy munkán többen dolgoznak, és az egyik embert átrakod máshová.

    Mondjuk erre meg:

    $oio->cut($emp,$tasks);



    Végülis egész jó a rendszer.
    A lényeg, hogy a kapcsolatokat csak munálisan lehet lekezelni, de active recorddal is szerintem ugyanez a helyzet.


    Mondjuk hozzám ez a fajta megközelítés sokkal közelebb áll:
    $user=new User(); $user->setId(12); $tasks=$user->getTasks(); $user->removeTask($tasks); //kapcsolatot szakít meg $tasks->delete(); //törli a munkákat egy az egyben
    Mutasd a teljes hozzászólást!
  • Szerintem lehet ezzel a szintaxissal is kapcsolatokat ábrázolni, csak kicsit komplikáltabb...

    $user=new User(); $user->setName('Petike'); $books=new List('Book'); $oio->get($user,$oio->relation('1:n','User','Book'),$books);

    Nyilván ha az ember előre megadja, hogy milyen a kapcsolat, akkor egyszerűsödik a dolog:

    $user=new User(); $user->setName('Petike'); $books=new List('Book'); $oio->get($books)->in_relation($user);

    vagy ilyesmi...
    Mutasd a teljes hozzászólást!
  • Az objektumokon belüli relációk (pl. kompozíció, hogy egy munkának van egy felelőse, ami egy Employee objektum) kérdésére viszonylag egyszerű a megoldás. Az implementációban is van ilyen, csak ott így kellene: $oio->save($munka, $felelos) (ez felépít egy egy-egy relációt, de lehetne pl., hogy ha a második paraméter tömb, akkor egy-sok relációt csináljon belőle). Könnyen megvalósítható lenne, hogy ha a menteni kívánt objektum egy mezője szintén objektum, azt a fenti függvényhívás módján mentse. Az egész persze elmélet, mert bár a tárolás még ilyen esetben megoldható sematikusan, de a lekérdezés már kevésbé (pl. ha lekérdezek egy munkát, akkor adja vissza a hozzá tartozó felelőst/felelősöket is?).

    Egyébként ez az egész egy ötlet, kísérlet, és itt remekül rávilágítottatok, hogy mi vele a hiba. Én is egyébként hagyományos ORM megközelítésben dolgozom, éppen, ahogy írtad is .
    Mutasd a teljes hozzászólást!
  • Ezek mind nagyon ésszerű és teljesen belátható érvek, nem is vitatkoznék semmivel. Köszönöm a hozzászólást.

    Az indexelésnél egyébként arra gondoltam, hogy a lekérdezések alapján építené fel az indexeket, magyarán pl. ha olyan objektumot kap, aminek ki van töltve a date és userId mezője, akkor létrehoz egy (date, userId) indexet. Erre egy teljeskörű intelligencia megírása mondjuk nehéz feladat (pl. akár csak azt kitalálni, hogy az indexelni kívánt mező unique-e). Itt már persze előre látható az a probléma, hogy bizonyos adatelérési kritériumokat nem lehetne normálisan objektumok mezőiként egyszerűen, megint csak valami konvenció kierőltetése nélkül megvalósítani. Pl. ha azokat a rekordokat akarom lekérni, ahol mező<x, akkor megint csak eljutottuk oda, hogy valamiféle SQL pótlék kell, ami nyilván nem pálya. És ez még mindig csak valami egyszerű lekérdezés.
    Mutasd a teljes hozzászólást!
  • Hát oo adatbázisnál én psepro-ról tanultam, ha mondjuk belőnéd, hogy mit tárolsz, és SOAP-pal átküldenéd java-nak, akkor felesleges lenne annyit kódolnod. (Az egyedüli gond vele, hogy fizetős.)
    Mutasd a teljes hozzászólást!
  • Én inkább valahogy a kettőt kombinálnám....
    Úgy értem, hogy a sima ID alapú dolgokra jó az active record, de mondjuk az összes március hónapban regisztrált user lekérdezésére már az a megadási mód a jó, amit te csináltál...
    Végülis tökmindegy, hogy hogy csinálod, a lényeg az, hogy valamilyen tranzakciókezelés mindenképp kelleni fog.

    Szerintem valahogy így bele tudnád vinni a tranzakciókezelést, de a lényeg, hogy mindenképp kelleni fog valamilyen kompromisszum a témában, tranzakciók nélkül ugyanis elég limitált lesz a dolog használhatósága...

    class User extends DAO... { setId($id); getId(); setEmail($mail); getEmail(); setPass($pass); getPass(); } class Model extends SomeShit { protected function _get_user($id) { $user=new User(); $user->setId($id); return $user; } public function __call($method,$arguments) { $callback=camelize($method); try { $transaction=$this->session->beginTransaction(); $result=call_user_func_array($callback,$arguments); $transaction->commit(); return $result; } catch(DataAccessException $e) { $transaction->rollback(); } } } $model=new Model(); $user=$model->getUser(123);

    Így belegondolva sok értelme nincs annak, amit kitaláltál, mert végül úgyis valami hasonló módon lesz elrejtve az adatbázis elérés, mint ennél a $model->getUser -nél...
    Mutasd a teljes hozzászólást!
  • Mondok egy egyszerű példát, ahol ez az egész megdől:

    Van egy munka osztályod. Ezen belül van neki felelőse.
    A felelősről az adatbázisban azonosítót tárolunk általában, de a felületen nevet jelenítünk meg.
    Ezt osztály szinten két módszerrel tudod megvalósítani:
    - vagy egy view-n keresztül éred el a munka táblát és itt joinolod a felhasználók vagy alkalmazottak táblát és lesz egy displayname property-d
    - vagy munka class egyik property-je egy alkalmazott class.

    Bármely esetről is van szó nem nagyon tudsz automatikusan ezzel mit kezdeni.

    Harmadik eshetőség, ha ezzel egyáltalán nem foglalkozol és menet közben töltöd fel az emberünk nevét - lista esetén egyesével zaklatva az adatbázist.

    Az egésznek a létjogosultságát nem látom be. Inkább egy olyan megoldást kellene csinálnod, ami egy osztályhoz megcsinál egy alap manager osztályt, amely az alapműveleteket (select, insert, delete, stb) végzi. Ezt php-ban legenerálod és utána ezt lehet módosítani, bővíteni. Ennek több értelmét látom.
    Mutasd a teljes hozzászólást!
  • Nem tudom már hol olvastam erről tanulmányokat, és én is osztom, hogy az egységbezártság és adatrejtés nem feltétlenül azt jelenti, hogy az objektum bizonyos mezőihez nem férünk hozzá kívülről közvetlenül, vagy akár mint itt, metóduson keresztül egy korlátozott formában.

    Az adatrejtés nem azt jelenti, hogy elrejtjük az adatokat a külső világ elől? Akkor minek hívják így?

    Valójában az egyetlen legitim ok a zártság és az adatrejtés elveinek megszegésére és áthágására a hibakeresés, tesztelés, ti. amikor azt akarod ellenőrizni, hogy mi egy adott objektum belső állapota ill. az -e amit te vársz, pl. egy unitteszt részeként. (Fontos azonban megjegyezni, hogy valójában itt sem az alapelv megszegéséről van szó, hizen az adott objektum és a hozzá kapcsolódó unittest valójában egyetlen, szoros egységet képez - csak éppen nem a nyelvi elemek szintjén, és ezért szükséges valahogyan a nyelvi adatrejtési korlátok kikerülése.)

    Az alkalmazási kódnak és logikának - pláne egy általános célú runtime keretrendszernek - azonban sosem szabad a rejtett mezők, metódusok, stb. elérésére építenie, mert az egész adatrejtésnek az a lényege, hogy ezekről a külvilágnak (az alkalmazáskódnak az objektumon kívüli részének) nem szabad még tudnia sem, nem ám elérni őket...

    Itt meg arról lenne csak szó, hogy valahogy az objektumnak azt kellene kifelé kommunikálnia, hogy belőle mi a mentendő.

    A baj azzal van, hogy ez így nem működik. A puszta mezőlista átadása nem működik, pontosan csakis akkor és addig működik, ha és amíg minden egyes mező leképezhető egy elemi adatbázismezőre, méghozzá közvetlenül. Ez azt jelenti, hogy belső objektumreferenciák, egy-több vagy több-több kapcsolatok, tömbök, stb. így nem ábrázolhatóak. A már említett erőforrások-típusok szintén nem, hiszen a külső menedzsernek gőze sem lehet arról, hogy az az erőforrás-azonosító honnan és hogyan jött létre, valamint hogyan kell és lehet újból létrehozni visszatöltéskor.

    Ha ezek mégis kellenek akkor ezen az elemi (rekordszintű) absztrakción túl ill. a felett kell még egy magasabb adatréteg, amiben megvalósításra kerülnek ezek. Ezen korlátok között azonban az egész automatizmus kb. értelmét veszti, hiszen kétszeresét elveszted a réven annak, amit megnyersz a vámon.

    Talán írtam is egy TODO kommentet, valamint van is erre egy (még semmit se befolyásoló) opció, hogy végezze-e folyamatosan az adatbázis-séma optimalizálását a rendszer.

    Elég kellemetlen ha minden egyes update potenciálisan az egész tábla - és benne akár többezer, tízezer, millió rekord - átvariálásával jár. Az már csak apróság, hogy ez nem is feltétlenül működik, mert pl. nem minden indextípus támogatott minden mezőn, és referenciaintegritás alapja sem lehet akármilyen mező. Már ha ilyenek megvalósításában is gondolkodsz, amit nyilván kell, ha már valami.

    Amit írsz a mostani rendszerekkel kapcsolatban, ha tényleg nem számít annyira a mező mérete, akkor meg teljesen le lehet egyszerűsíteni a dolgokat. Egyébként szerintem indexelésnél már egyáltalán nem mindegy, hogy mekkora mezők szerepelnek az indexben.

    Na, ez a másik dolog, hogy honnan fogod tudni, hogy mely mezőket kell indexelni? Vagy mindent indexelsz? Akkor marha lassú lesz minden update/insert művelet rajta, és a legtöbb index hallott, kihasználatlan lesz. Ha meg pl. az első lekérdezéskor hozol létre indexet, akkor attól függően, hogy arra mikor kerül sor, az adott meg az azt X másodpercen, percen, órán belül követő lekérdezések is mind jó eséllyel meg fognak feküdni timeouttal.

    Hatványozottan igaz lesz ez összetett lekérdezésekre, keresésekre, ahol pl. két vagy több mező értéke alapján kell majd egy rekordot megkeresni.

    Tömbökkel kapcsolatos implementáció is még nincs. (Itt arra gondoltam egyébként, hogy a tömb elemeit külön táblába lehetne menteni, egy-sok relációt felépítve az eredeti objektumhoz. Ez, amíg a tömb egydimenziós és ilyen "menthető" objektumokat tárol, egyszerű.)

    Mindezzel csak az a baj, hogy a keretrendszer magától nem tudhatja, hogy ezt érdemes -e így csinálni vagy sem, azaz, hogy pl. az alkalmazási logikának valaha is szüksége lesz a tömb elemeinek közvetlen elérésére adatbázisszinten (pl. kereséshez). Ha nem, akkor ez az erőforrások óriási pocsékolása lesz, ami rendkívül belassít majd minden műveletet, és a memóriahasználatot is rendkívüli mértékben megnyomja.

    Pontosan ezért kell az objektumra bízni minden ilyen dolgot - ti. hogy milyen adatát és hogyan akarja menteni -, és egy keretrendszernek max. csak szervízrutinokat biztosítai ehhez; de a mentési halmaz és mód meghatározását sosem szabad egy általános célú rendszerre bízni, mert az sosem fog tudni olyan optimális megoldást létrehozni, mint a program azon része, amely pontosan ismeri az alkalmazási logika szükségleteit, "szokásait".

    Erőforrásokat meg talán nem is kellene menteni? Sőt, ha jól tudom PHP-ben ezeket nem is lehetne.

    A te rendszeredben persze hogy nem. Éppen ez a lényeg. Ugyanakkor ezek úgymond mentése és helyreállítása is megoldható, ha a mentést az objektum saját maga végzi (ő ugyanis pontosan tudja hogyan hozta létre az erőforrást, és újból létre tudja hozni, ill. legalábbis megpróbálni).

    Hiszen azért is indítottam a topicot, hogy megkérdezzem, egyébként ennek az egésznek így van-e értelme? Szerinted ezek szerint nincs.

    Hát, mint írtam, ebben a formában csak a legegyszerűbb, legelemibb struktúrák kezelésére alkalmas - és azokéra is elég ineffektíven -, ám a valós életben akár csak egy egyszerű webshop esetében előforduló adatbázis leképezésére már tökéletesen alkalmatlan. Ill. akkor alkalmas, ha ráraksz még egy adatkezelési réteget, ahol megjelennek a rekordszintnél nagyobb összefüggések. Ebben az esetben viszont értelmét veszti az egész, hiszen - ha jól értem - pont az lenne a célja, hogy levegye az elemi adatkezeléssel járó nyűgőt a programozó válláról - ha helyette viszont egy ugyanakkor vagy még nagyobb nyűgőt és plusz munkát akaszt a vállára, akkor okafogyottá válik az egész.
    Mutasd a teljes hozzászólást!
  • Valóban.

    Amit írsz a szerializálásról nagyon érdekes, a pythonos példa pedig különösen, ilyesmire még soha nem is gondoltam.

    Írtam üzenetet.
    Mutasd a teljes hozzászólást!
  • Még valami: ez a getFields() hasonló funkciót lát el, mint a __sleep(), a setFields() pedig mint a __wakeup(). Az pedig, hogy nem csak propety-neveket, hanem értékeket is visszaad pl. a getFields() amiatt van, mert ugye a keretrendszer nem PHP, és nem fér hozzá az objektum összes - mentendő - mezőjéhez . Egyébként most már úgy látom az egész próbálkozásom arra irányult, hogy valamiféle ODBMS architektúrát valósítsak meg, RDBMS alapokon...
    Mutasd a teljes hozzászólást!
  • Nem tudom már hol olvastam erről tanulmányokat, és én is osztom, hogy az egységbezártság és adatrejtés nem feltétlenül azt jelenti, hogy az objektum bizonyos mezőihez nem férünk hozzá kívülről közvetlenül, vagy akár mint itt, metóduson keresztül egy korlátozott formában. Itt meg arról lenne csak szó, hogy valahogy az objektumnak azt kellene kifelé kommunikálnia, hogy belőle mi a mentendő. Ha jól értem szerinted ez nem így működik, szerintem ezzel nincs probléma. De ez már filozófiai kérdés.

    Az implementáció meg ahogy említettem is, nagyon primitív. Talán írtam is egy TODO kommentet, valamint van is erre egy (még semmit se befolyásoló) opció, hogy végezze-e folyamatosan az adatbázis-séma optimalizálását a rendszer. Mert kezdésnek veszi a lehető legkisebb adattípust, majd ha egy később tárolandó mező azt kinövi, átalakítaná más típusúvá. Amit írsz a mostani rendszerekkel kapcsolatban, ha tényleg nem számít annyira a mező mérete, akkor meg teljesen le lehet egyszerűsíteni a dolgokat. Egyébként szerintem indexelésnél már egyáltalán nem mindegy, hogy mekkora mezők szerepelnek az indexben.
    Tömbökkel kapcsolatos implementáció is még nincs. (Itt arra gondoltam egyébként, hogy a tömb elemeit külön táblába lehetne menteni, egy-sok relációt felépítve az eredeti objektumhoz. Ez, amíg a tömb egydimenziós és ilyen "menthető" objektumokat tárol, egyszerű.) Erőforrásokat meg talán nem is kellene menteni? Sőt, ha jól tudom PHP-ben ezeket nem is lehetne.

    Köszönöm szépen a hozzászólásodat, nagyon építő volt. Hiszen azért is indítottam a topicot, hogy megkérdezzem, egyébként ennek az egésznek így van-e értelme? Szerinted ezek szerint nincs. A célom az ezzel a megközelítéssel az, hogy az objektum-hierarchia ne az adatbázis-struktúra leképezése legyen, vagy fordítva, ne minden objektumot egy táblához kössünk. (Ezen kívül nem tetszik még, hogy sok ORM rendszer aztán valami pszeudo-SQL-t vezet be bonyolultabb querykhez.) Az objektumokat ne használjuk másképp, mint ha nem is relációs adatbázisban akarnánk aztán tárolni őket. Az idea valamennyire olyasmi, mintha az éppen erre szolgáló NoSQL adatbázis-rendszerek működését akarnánk imitálni. Kérdés persze, hogy akkor már nem jobb-e egyből NoSQL-t használni.
    Mutasd a teljes hozzászólást!
  • Ha jól értem a te megoldásod inkább "hagyományos" megközelítésű ORM. Ugye arra szerettem volna kilyukadni, hogy némileg - szerintem - természetesebb utat választottam azzal, hogy nem az objektumban kell gondoskodni arról, hogy hogyan mentse magát, hanem azt a keretrendszer végzi "kívülről".

    Ez nagyon nem a természetesebb út egy OOP modellben, sőt, tökéletesen ellenkezik az OOP alapelveivel. Ebből ugyanis az a két dolog következik, hogy egyrészt az objektum maga tudja, tudhatja csak pontosan, hogy hogyan is kell a saját tartalmát valami perzisztens tárolóba elmenteni, másrészt pedig, hogy ha ez egy rendesen megírt objektum egy rendes OOP rendszerben, akkor a külső mentés technikailag is lehetetlen az objektumok zártsága miatt (ti. hogy vannak ill. lehetnek privát vagy védett mezői, amik kívülről nem hozzáférhetőek közvetlenül).

    A konkrét implementációban ráadásul én olyan problémákat is látok pl. hogy a mező típusát a létrehozást kiváltó tábla akkori konkrét értékei alapján próbálja meg leszűkíteni, ami teljesen értelmetlen és hibás működéshez vezet. Értelmetlen azért, mert a mai 32/64-bites processzorokon, rendszereken a 32/64-bitnél rövidebb mezők kezelésével (kezelésének kísérletével) sem időt sem memóriát nem lehet nagyon megspórolni, sőt, csak lassítja dolgokat. Hibás működéshez pedig azért vezet, mert ha pl. az első rekordot 1-es ID-vel viszem fel, akkor ID mezőmet tinyint-re fogja megcsinálni, ami azt jelenti, hogy máris belimitálta a maximális rekordszámom 256-ra (ami nyilván nonszensz), még akkor is, ha szigorúan egyesével növelem eztán az ID-t. (Az ID helyett persze bármilyen másik mezőre is igaz ez, a numerikus mellett a szöveges típusúakra is.)

    A komplex (elemi SQL mezőben nem ábrázolható, pl. tömb) ill. erőforrás típusú mezők mentésének problémáját szintén teljesen ignorálja a megközelítés, amire azonban nem vesztegetnék sok szót már, mert azt hiszem a fentiek alapján is teljesen nyilvánvaló, hogy ez így ebben a formájában egy halvaszületett ötlet, ami csak igen korlátozott (a valós életben megoldandó legegyszerűbb feladatok befogadására sem alkalmas) peremfeltételrendszer teljesülése esetén lehet képes csak működni.
    Mutasd a teljes hozzászólást!
  • Lényegében a te és az én megoldásom között semmi különbség sincs. Végeredményben így is egy külső objektum végzi az objektum tárolását és minden mást, csak én leszármaztatom ebből a tárolandó objektumomat. Át lehet írni úgy is, hogy $this->serialize() helyett $kulso_objektum->serialize() legyen, és így már pont az amit te leírtál.

    A szerializálást és indexelést úgy hoztam össze, hogy miután a Java szerver megkapta a szerializált stringet, azután szépen feldolgozza, kiszedegeti belőle az objektum nevét, az id-t, a többi változót és az értéküket és így tárolja. Így már lehet rendezni id, vagy akármi alapján, lehet keresni benne, ...stb.

    Plusz ennek van egy nagy előnye: írhatok hozzá pl egy Python plugint, ami képes feldolgozni a szerializált Python objektumokat. Így meg lehet azt vele csinálni, hogy bedobok egy PHP objektumot és kiveszek egy Python objektumot.
    Mutasd a teljes hozzászólást!
  • Hát jó .
    Egyébként lehetne pl. az, hogy (opcionálisan) eleve csak azokat a mezőket tölti fel kiolvasáskor, amiket (üresen) visszaad a getFields() (hiszen kiolvasáskor egyébként is meghívja a keretrendszer az objektumnak ezt a függvényét, és az visszakapott id vagy webId kulcsú tömbelem alapján fut le a query).
    Az objektum mentésekor meg ahogy írtam a getFields() eleve a megváltozott mezőket adhatná vissza (mert a getFields() által adott mezőket menti csak), de ez ugye munkás.
    Mutasd a teljes hozzászólást!
  • Szia!

    Ha jól értem a te megoldásod inkább "hagyományos" megközelítésű ORM. Ugye arra szerettem volna kilyukadni, hogy némileg - szerintem - természetesebb utat választottam azzal, hogy nem az objektumban kell gondoskodni arról, hogy hogyan mentse magát, hanem azt a keretrendszer végzi "kívülről". Hiszen egy almát is a kosárba rakjuk be és onnan vesszük ki, de nem az almát alakítjuk attól függően, hogy kosárba vagy ládába pakoljuk-e .
    Ettől függetlenül örömmel dolgoznék együtt, bár Java-ban semmi tapasztalatom (PHP-n kívül natív C++, C#) OFF: Az egyébként érdekelne is, a szerializációt és indexelést hogyan hoztad össze. Nem rég gondoltam arra, hogy az egyszerűség kedvéért objektumokat inkább szerializálva kellene egy sima szövegmezőben tárolni, ugyanis sok, sokféle, de kis méretű objektumról volt szó, így nem akartam volna mindegyik típust egy-egy táblához kötni (nomeg a PHP (un)serialize() elég gyors ehhez). Az indexelés, fulltext keresés miatt azonban mégis a hagyományos megközelítés mellett döntöttem.
    Mutasd a teljes hozzászólást!
  • Én inkább úgy fogalmaznék, hogy bizonyos méret alatt így is működőképes a kód.
    Mutasd a teljes hozzászólást!
  • Ugye itt a filozófia az, hogy az objektum mondja meg, hogy mit kell menteni. Persze nyilván nem kényelmes, ha a getFields() visszatérési értékét aszerint kell változtatni, hogy mi változott az objektumban.
    Egyébként valóban pazarlás azt is menteni, ami nem változott, de szerintem ez belefér. Valahol olvastam korábban - igaz, ez csak kiolvasás, hogy óriási és rengeteg sorokat leszámítva nincs gyakorlati különbség a SELECT (*) és az egyes oszlopok lekérdezése között. Ugyanis ha a lemez feje már megtalálta a sor elejét, akkor gyorsan végigolvassa, nem számottevő, ha csak a feléig kell. Persze lesz különbség, és adatbázisa és terheltsége válogatja, hogy mennyi.
    Mutasd a teljes hozzászólást!
  • Szia!

    Pontosan egy ilyet írok PHP-hoz, csak nekem az objektumokat nem relációs adatbáziskezelő tárolja, hanem egy saját Java-ban írt "adatbázis" szerver.
    A működéséről annyit, hogy van egy Model nevű PHP objektum, ez tartalmazza az adatbázisba kiíráshoz, olvasáshoz, ..stb szükséges metódusokat, ebből kell származtatni az objektumot amit tárolni akarunk. A Model->put() metódussal szerializálja magát az objektum, majd továbbítódik a szervernek, a szerver feldolgozza, és tárolja, indexeli...stb.
    Ha érdekel a dolog akkor összefoghatnánk.
    Mutasd a teljes hozzászólást!
  • A megközelítésnél kell legalább még egy külső objektum, ami jegyzi, hogy mondjuk egy setName vagy setEmail esetén mi kapott új értéket, különben az egész sort kéne updatelned, ami pazarlás. Kiolvasásnál ugyanúgy az egészet olvasod ki a jelenlegi formában, ami megint csak pazarlás.

    Kéne valamilyen felület, amin meg tudod határozni, hogy pontosan milyen mezőkre van szükséged. Egy ilyet kigondolni nem éppen egyszerű...
    Mutasd a teljes hozzászólást!
  • Címre nem jutott eszembe jobb. Arról lenne szó, hogy elkezdtem írogatni egy adatelérési réteget (azt hiszem ez az), ami némileg ellentétes irányból közelíti meg az ORM elvet. Itt nem az van, hogy "van ez az objektum, akkor mentse el magát", hanem "itt ez az objektum, mentsük". A "mentsük"-et végzi (végezné) ez a rendszer. Egyelőre persze elég kezdetleges. Lehet, hogy egyébként ezt persistence frameworknek nevezik?


    Bővebben:
    Az egész játék arra megy ki, hogy objektum-orientált programozási környezetben (most konkrétan PHP-ről van szó, és kérem a kuncogást abbahagyni) ne kelljen relációs adatbázis-eléréssel foglalkozni, egyáltalán. Az, amire én gondoltam (és úgy tűnik, pont ilyen nincs, de javítsatok ki, ha tévedek) egy olyan keretrendszer, amivel úgy lehet CRUD műveleteket végezni, hogy nem változtatunk nagyon az objektumokon ORM kedvéért. Konkrétan pedig mindez működhetne úgy, hogy ennek a rendszernek dobáljuk az objektumokat, amit ő eltárol valahogy (az adatbázis-sémát kitalálja magától), majd ezeket hasonló módon, objektumokkal tudjuk kinyerni.
    Amit elkezdtem írni, OIO-nak neveztem Object I/O után (meg persze azért is, mert milyen jó már így ez a három betű).

    Egyszerű példa:
    (Pszeudokód persze.)

    // mentés UserObject user user.name = "Pista" user.email = "pista@muvhaz.hu" oio.save(user) // kiolvasás UserObject anotherUser anotherUser.name = "Marcsi" oio.get(anotherUser) // a kiolvasott adat benne van az anotherUser-ben

    A háttértároló szerepét egy relációs adatbázis tölti be, ahol az adatbázis-sémát a keretrendszer folyamatosan optimalizálja a tárolt adatok alapján.
    Jócskán lehetne itt még bonyolítani, pl. relációk itt is kellenének. Egy-egy reláció lehetne pl. így:

    BlogPost post post.title = "Cím" post.text = "szöveg szöveg szöveg" UserObject user user.name = "Töhötöm" oio.save(post, user)


    Mi van meg?
    Mellékletben ott a meglévő kód.
    Annyi, hogy objektumokat lehet a vázolt egyszerű, illetve egyszerű egy-egy relációs módon menteni, ahol a keretrendszer primitív módon megtippeli, hogy hogyan kellene ezeket tárolni. Kétszer ne is próbáljatok ugyanolyan típusú objektumot menteni, mert újra létre akarja majd hozni a táblát. Ez azért van, mert a DBSchema classban, ami meglepő módon az adatbázis-sémát tárolja (cacheli, hogy ne kelljen állandóan az adatbázishoz nyúlni), nincs még implementálva, hogy hozzáadja a cache-hez az újonnan létrehozott tábla adatait. (Ha törlitek a cache fájlt, ami alapesetben DBSchema.oio, akkor újraépíti a cache-t a tényleges sémából, utána már megy.)
    Lekérdezés működik úgy, hogy egy id vagy webId "mezőjű" objektumot vár.
    Azért idézőjelesen a mező, mert más ORM rendszerekkel ellentétben ez nem magától veszi az összes (publikus) mezőt, mert szerintem ez így nem értelmes. Az objektumban kell lennie getFields() és setFields() függvényeknek (DBObjectInterface), amik tetszőleges módon manipulálják a menteni kívánt mezőket.
    A kód nincs még dokumentálva, de a nevek elég beszédesek. A test.php-n lehet elindulni, ott van egy egyszerű példa. Az OIO.php-ben ér össze a rendszer, ott a get() és save() függvényekből indul minden.


    Minden hozzászólást, javaslatot, kritikát örömmel fogadok, leginkább meg arra lennék kíváncsi, hogy ez az elgondolás egyáltalán mennyire új?
    Mutasd a teljes hozzászólást!
    Csatolt állomány
abcd