Ezt is jó tudni, köszönjük!
Én személy szerint kíváncsi lennék a gyakorlati használatára is - a saját tesztedet esetleg nem publikálod?
Ugyanezt akkor lehetne alakítgatni egyéni tesztek írására is.

Btw. örülök, hogy valaki itt PH!-n haladó módon is foglalkozik a PHP-val, és végre nem csak olyan színvonalú írásokat látni, hogy "hogyan validáljunk és dolgozzunk fel egy formot szerveroldalon PHP-val". Így tovább!

[ Szerkesztve ]

Sk8erPeter

gyakorlati hasznát én ennek pl. a Kohana ORM moduljában láttam, ahol egy lekérdezés pl.:
ORM::factory('Entitas')->find_all()
egy iterálható objektumot ad vissza entitásokról, és végig lehet rajta menni foreach-csel. A háttérben pedig a mysql result set-ből dolgozik. Az értelme valami olyasmi, hogy nem alakítja az összes adatbázis sort objektummá, csak akkor, amikor konkrétan el akarod érni.

Ezt jó tudni.
Egyébként a korábbi hsz.-emben arra céloztam, hogy kíváncsi lennék, hogyan nézett ki Athlon64+-nál az összehasonlítás (maga a kód), de rájöttem, hogy a hivatalos oldalon mutatott IteratorAggregate-re mutatott példa annyira egyszerű, hogy túl szép, hogy igaz legyen.

..............
public function getIterator() {
return new ArrayIterator($this);
}
..............

Hát ez ilyenformán nem egy nehéz valami.
Gondolom ilyenre lefuttatott egy buzinagy ciklust egy kis mérőkével, meg a másikra is, és kész.

(#1) Athlon64+ :
"[értesítő]"
így nem egyszerűbb? >>

[ Szerkesztve ]

Sk8erPeter

Megoszthatom a tesztet, de nem akarok nevetség tárgya lenni, annyira faék.

Gyakorlati használata rém egyszerű (egyszerű példában persze ):

class IT implements IteratorAggregate {

protected $_a = array();

public function getIterator() {
return new ArrayIterator($this->_a);
}

}

TableEntity-mben:
abstract class TableEntity extends \System\ObjectBase implements \IteratorAggregate, \System\Collections\IEnumerable {

/* ... */

public function getIterator() {
return new \ArrayIterator($this->ToArray());
}

}

---

Amint kiküldöm az első hozzászólást, kapcsolok is rá a borítékra.

Nem hiszem, hogy ilyen varázslat lenne a Kohana-ban. Túlságosan bonyolítaná a dolgokat, ha nem fetchelnék objektummá azonnal az elemeket, mondom ezt úgy, hogy építettem ORM-et. Az előző hozzászólásomban írtam, hogyan pakoltam bele az enyémbe, annál fogva:

foreach ($dataContext->Members() as $member) {
/* ... */
}

Gyakorlatban használok ilyet mindenféle container (EntitySet, ObjectGroup, Enumerable, stb) bejárására, de pl. a Config osztályom is tudja, ott a gyerek elemeket lehet bejárni (XML-ből táplálkozik). De pl. a saját session-kezelésből adódik egy ACSession osztályom, aminél a $_SESSION-t tudom bejáratni, ha ahhoz van kedvem.

Attól még, mert írtál ORM-et (ami önmagában azért nem varázslat, még ha szopó feladat is lehet), egy másik framework miért ne működhetne másképp, mint ahogy Te megírtad?
modder ismeri a Kohanát, dolgozott vele, arra alapozva mondja.
Azt mondjuk nem értem, Te mire alapozva cáfoltad, hogy nem úgy működik, ahogy ő írta, ha ezek szerint meg sem nézted.

Én nem ismerem a Kohanát, ezért vettem rá a fáradságot, hogy letöltsem a keretrendszert és megnézzem, mi lehet az igazság, itt van kimazsolázva az érintett kódrészlet:

class Kohana_ORM extends Model implements serializable {

//...................................................

/**
* Database query builder
* @var Database_Query_Builder_Where
*/
protected $_db_builder;

//...................................................

/**
* Initializes the Database Builder to given query type
*
* @param integer $type Type of Database query
* @return ORM
*/
protected function _build($type)
{
// Construct new builder object based on query type
switch ($type)
{
case Database::SELECT:
$this->_db_builder = DB::select();
break;
case Database::UPDATE:
$this->_db_builder = DB::update(array($this->_table_name, $this->_object_name));
break;
case Database::DELETE:
$this->_db_builder = DB::delete(array($this->_table_name, $this->_object_name));
}

// Process pending database method calls
foreach ($this->_db_pending as $method)
{
$name = $method['name'];
$args = $method['args'];

$this->_db_applied[$name] = $name;

call_user_func_array(array($this->_db_builder, $name), $args);
}

return $this;
}


//...................................................

/**
* Finds multiple database rows and returns an iterator of the rows found.
*
* @return Database_Result
*/
public function find_all()
{
if ($this->_loaded)
throw new Kohana_Exception('Method find_all() cannot be called on loaded objects');

if ( ! empty($this->_load_with))
{
foreach ($this->_load_with as $alias)
{
// Bind auto relationships
$this->with($alias);
}
}

$this->_build(Database::SELECT);

return $this->_load_result(TRUE);
}

//...................................................

} // End ORM

Na most a többi érintett kódrészletet már nem másolgatom be, mert akkor kicsit hosszú lenne a hozzászólásom, de ami ebből is látható (meg a többi kódrészletből), az alátámasztani látszik azt, amit modder írt.

===

(#5) : Ezek szerint addig nem jelenik meg a buborék, amíg meg nem jelenik az első hsz.? Hmm.
A példára rátérve igazából arra lettem volna kíváncsi, hogyan tesztelted, ami miatt a sima Iterator interface implementációjával történő tesztelés elszállt futási idő túllépésével. Meglepő, ha ekkora a különbség, ilyen esetben meg azért nem árt tudni, mi volt a tesztkörnyezet, amiben ez teljesült.

Sk8erPeter

Ebből semmi sem látszik, mert ez csak query builder + végrehajtás, de az eredmény már nincs benne. modder azt írta, hogy folyamatosan fetchel, ebben ez nincs benne, és én ezt kétlem. Azt, hogy iterálható az adathalmaz, az nem vita tárgya, az, ha működik.

---

Nem, addig nem jelenik meg.

Core i5 @3GHz 1 magon 128 vagy 256 MB memóriát adva a PHP-nak.

"mi volt a tesztkörnyezet"
Itt eléggé pontatlan volt, amit írtam, mert nem csak a konfiguráció érdekelt volna, hanem a konkrét kód.

A Kohanás kódra:
igazából abbahagytam a bemásolást, és nem raktam be azt, amit még kellett volna: a _load_result() függvényt:

..............
/**
* Loads a database result, either as a new record for this model, or as
* an iterator for multiple rows.
*
* @chainable
* @param bool $multiple Return an iterator or load a single row
* @return ORM|Database_Result
*/
protected function _load_result($multiple = FALSE)
{
$this->_db_builder->from(array($this->_table_name, $this->_object_name));

if ($multiple === FALSE)
{
// Only fetch 1 record
$this->_db_builder->limit(1);
}

// Select all columns by default
$this->_db_builder->select($this->_object_name.'.*');

if ( ! isset($this->_db_applied['order_by']) AND ! empty($this->_sorting))
{
foreach ($this->_sorting as $column => $direction)
{
if (strpos($column, '.') === FALSE)
{
// Sorting column for use in JOINs
$column = $this->_object_name.'.'.$column;
}

$this->_db_builder->order_by($column, $direction);
}
}

if ($multiple === TRUE)
{
// Return database iterator casting to this object type
$result = $this->_db_builder->as_object(get_class($this))->execute($this->_db);

$this->reset();

return $result;
}
else
{
// Load the result as an associative array
$result = $this->_db_builder->as_assoc()->execute($this->_db);

$this->reset();

if ($result->count() === 1)
{
// Load object values
$this->_load_values($result->current());
}
else
{
// Clear the object, nothing was found
$this->clear();
}

return $this;
}
}
.....

Sk8erPeter

Melóban vagyok, a kód nincs nálam.

---

Az plusz kód sem árul el semmit sem arról, hogyan fetcheli az obejktumokat. Egyébként szerintem nagyon f.s érdekes ez a kód.

Ő, hát szerintem sem a legszebb.

Sk8erPeter

de a $this->_db_builder->as_object mit csinál?

Egyébként már nem is tudom mit írtam, hogy csinálja a Kohana, lehet, hogy nem volt igazam. De már tudok jobb példát mondani arra a kérdésre, hogy mi ennek a gyakorlati alkalmazása, ami Sk8erPeter eredeti kérdése volt.

Ugye az iterátort tudjuk, mire jó: egy interfészt ad egy tároló elemeinek végigléptetéséhez a belső reprezetnációtól függetlenül. A PHP által definiált iterátor interfész pedig mindezt egységessé teszi, hogy a PHP-ban használatos vezérlési szerkezetekkel is megfelelően működjön: foreach, array_map stb...

Szóval ez az interfész bármikor jó, amikor egy iterátor jól jön:

-- 1) Az egyik eset, amire gondolni tudok, az a fentebb említett. Például van egy gráfod, és annak a csúcsait akarod bejárni egyenként.

-- 2) Speckó dolog, amire én gondoltam Kohanával kapcsolatban, hogy a tárolt adatok reprezentációja (típusa) nem egyezik meg azzal, amit mi elvárunk az adatstruktúra interfészétől, hogy adjon, de az iterátor a megfelelő formátumra konvertálja.

Például a mysql result set egy stdClass (vagy amit a mysql_fetch_object visszaad) típusú objektumkat a vissza, de amit várunk a Kohanától, az a megfelelő ORM objektum minden esetben.
Ekkor véleményem szerint mindenképpen értelmesebb dolog lazy módon konvertálni az eredmény sorokat a megfelelő ORM objektumokká olyan egyszerű megfontolások miatt például, mint hogy a fejlesztő nem biztos, hogy minden eredményben megjelenő objektumot fel akar használni.

Igazad van, a Kohana adatbázis apija egy undorító katyvasz legalábbis nekem eddig ez jött le, plusz dokumentálatlan, és sokszor (amit a típustalanság miatt egyébként is probléma a tákolmány szar php-ban ) mást adnak vissza a függvények egy esetben, mint másik esetben bizonyos belső állapotoktól függően, például attól függően, hogy egy elemet várunk vagy többet, ugyanaz a függvény vagy egy objektumot ad vissza vagy egy iterátort...

[ Szerkesztve ]

Igazából eredetileg nem arra kérdeztem rá, hogy ez mire jó, hanem hogy hogyan néz ki kód szintjén az, amit Athlon64+ írt, ezt értettem "gyakorlati használat" alatt, nem a "gyakorlati hasznára" kérdeztem rá, mert arra vannak bőven ötleteim.
De azért nem árt, hogy megbeszéljük ezt is.

A mysql result set nyilvántartásának preferálását mondjuk nem feltétlenül tartom egyszerűbbnek, mert akkor nyilván kell tartani azt is, amit már mondjuk fetch-eltünk. Mondjuk valóban erőforráskímélőbb lehet a result set buzerálása, de kód szintjén lehet, hogy melósabb. Aztán lehet, hogy van rá valami ultimate megoldás, ami megteremti a világbékét.

Szerk.: a "tákolmány szar PHP" segítségével.

[ Szerkesztve ]

Sk8erPeter

Ez annyira szép, hogy mindenki ORM-et akar csinálni. Én is így kezdtem. Aztán jött a rios (ez bármely komplexebb rendszer nevével helyettesíthető)...

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Itt senki nem beszélt ORM-készítési szándékról.

Amúgy hogy őszinte legyek, meglehetősen nagyképűre sikerült a hozzászólásod.
Kb. így hangzott: valamikor még én is azon szenvedtem, hogy hogyan validáljak formot - Ti kis hülyegyerekek. Pedig vélhetően nem tudod behatárolni, itt ki mennyi időt szánt PHP-s fejlesztésekre.

[ Szerkesztve ]

Sk8erPeter

(#17) Sk8erPeter: Nagyképűség ON

Nem kell fetchelni:

class PostgresResult implements Iterator
{
private $_connection;

private $_result = NULL;

private $_key = 0;

private $_size;

private $_cache = array();

public function __construct($connection)
{
$this->_connection = $connection;
}

public function __destruct()
{
pg_free_result($this->_result);
}

public function current()
{
if($this->_result === null) {
$this->_result = pg_get_result($this->_connection);
$this->_size = pg_num_rows($this->_result);
}
if(!isset($this->_cache[$this->_key])) {
$this->_cache[$this->_key] = pg_fetch_assoc($this->_result, $this->_key);
}

return $this->_cache[$this->_key];
}

public function key()
{
return $this->_key;
}

public function next()
{
$this->_key++;
}

public function rewind()
{
$this->_key = 0;
}

public function valid()
{
return $this->_key < $this->_size;
}
}

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

[KÖCSÖG MÓD ON]
Legalább most életemben először hallottam azt a két nemlétező szót, hogy "konstruktálás", "destruktálás". Vagy csak lemaradtam róla.
[KÖCSÖG MÓD OFF]

Sk8erPeter

Régi kód még ifjonc koromból. Közbe a kommentedtől függetlenül kitöröltem, mert sok helyet foglalt a szöveg.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Pedig jó volt az a komment oda.

(#20) modder : szerintem meg neked nincs igazad.
"nem jövőbeli szándékra utalt"
Akkor olvasd el ezt még egyszer: "Ez annyira szép, hogy mindenki ORM-et akar csinálni. Én is így kezdtem. Aztán ..."
Most nem szeretnék nyelvtani mondat-elemezgetésekbe belemenni, de ez arra utal, hogy "Ti még ott tartotok, hogy ORM-et akartok csinálni, nálam is volt egy ilyen időszak, de azóta komolyabb dolgokkal foglalkozom". Erre mondtam, hogy enyhe nagyképűség.
Remélem így már sikerült összerakni.
De mondatokon való lovaglásba ne menjünk bele.

Sk8erPeter

Mi ez itt, irodalom óra, verselemzés? Vajon a költő mire gondolt?

Amúgy én nem akartam nagyképűsködni, szerintem tök jó amikor valakik ekkora lelkesedéssel ontják magukból a kódot.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Nyugodtan nagyképűsködhetsz, legfeljebb majd jól nem veszünk emberszámba. (nehogy magadra vedd )

Amúgy úgy tűnik, eléggé nem figyeltél az elejére, a tiéd előtt csak a Kohanából voltak itt kódrészek (meg persze az eredeti témakör kapcsán egy rövid kódrészlet), mert megvalósítási módszerek előnyeiről/hátrányairól diskuráltunk.

Sk8erPeter

"én meg csak azt akartam mondani, hogy az hamis állítás, hogy "itt senki nem beszélt ORM-készítési szándékról"."
Nem hamis állítás, mert a "szándék" az egy jövőbeli cselekedetre utal, tehát arra, hogy vélhetően itt épp készül valaki ORM-et írni.

""én már készítettem ORM-et" nagyvonalúan az állítmányból, a tárgyból és az alanyból tekintve ORM készítési szándékra utal."
Ha már belementél: nem, ez nem szándékra utal, hanem múltbeli, megtörtént cselekedetre. A "szándék" ugyanis nagyjából egy törekvés valamilyen későbbi cselekedetre.
Mindezt most csak azért mondtam el, mert erősen belekötöttél a saját mondatom jelentésébe is, de én sem akarom folytatni a mondattani elemzéseket.

Abban igazad van, hogy lezso6 eredeti hozzászólásának szándékát vélhetően félreértettem, azt gondoltam, konkrétan a mi diskurzusunkat tünteti fel nevetséges színben - pedig igazából valószínűleg csak arra utalt, hogy milyen vicces belegondolni, hogy amikor az ember még a tanulási folyamat elején vagy közepén van, akkor még olyan nagyvonalú tervei vannak, hogy ORM-et készít, frameworköt épít, és így tovább... Aztán ráébred, hogy szórakozzon vele a hóhér. Használ egy népszerű, sokak által felügyelt kódbázist.
Ez a vita nem indult volna el, ha lezso6 egyértelműbben fogalmaz.

Sk8erPeter

Naaa. Nem erről szól a topik.

Mi volt a sebességteszt kódja? Én nagyon kíváncsi lennék rá, mivel egy IteratorAggregate azért jóval kevesebbet tud, mint egy igazi Iterátor. Én az Iterator interfészt arra szoktam használni, hogy külső forrásból kapott adatokat tudjak hatékonyan tömbként kezelni. Pl adatbázist.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Erre én is kíváncsi lennék.

===

(#32) modder :
Te se! :megalázkodóssmiley: , ja megvan,

[ Szerkesztve ]

Sk8erPeter

Többet tudhat, de amikor semmi szükség rá, akkor felesleges bohóckodni vele.

---

lassú
gyors

Ja, hogy így. Igen, amire a teszt használja arra tényleg az iterator aggregate való. Vagyis nem, még az is sok neki. Erre elég az ArrayObject. Full C, úgyhogy az még gyorsabb lesz.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Szerintem sokkal gyorsabb már nem lehet, de az egyik osztályomat lehet, hogy ettől kellene származtatni. Ezen még gondolkodnom kell.