ORM layer voor PHP

[buurtnerd]

Hoi
Ik ben op zoek naar mensen die het leuk vinden om mijn ORM layer voor PhP te testen. Deze is tevens gratis te gebruiken en open source. De ORM laag is een beetje bijzonder omdat hij een complete database 'verzint' op basis van je code. Je hebt dus geen configuratie bestanden nodig, geen SQL import en geen mappings, alles gaat on the fly. Je hoeft zelfs geen classes aan te maken voor models. Zodra je een model gebruikt bestaat het opeens. Verder voegt het systeem zelf kolommen toe, verbreed het kolommen en vernauwd het kolommen. Het heeft een garbage collector die leegstaande tabellen en kolommen opruimt, een perf. monitor die extra indexes plaatst als een tabel langzaam wordt en automatische locking (tegen race condities) en transaction handling.

het adres is:
http://www.buurtnerd.nl/redbean.htm

de github is:
http://github.com/buurtnerd/redbean/tree/master

ben benieuwd of jullie het kapot krijgen

 

[Anotherhero]

Sorry, ik ben niet zo ver gekomen dat ik het kapot heb gekregen.
Tot dusver doet het gewoon wat het zegt dat het zou moeten doen.

Mag ik vragen waarom je voor deze syntax gekozen hebt?
$post->setContent('Hoi inhoud');
Zou een syntax als
$post['content'] = 'Hoi inhoud';
niet mooier zijn?

Bij SimpleXml is de ArrayAcces ook de toegang tot de attributen van een node.


Hoe zou de performance zijn als ik een grote dataset ophaal via de find functie?
Als ik bijvoorbeeld 200 items via de find functie ophaal doet de code daar nu 201 queries voor als ik het goed begrijp toch?

 

[buurtnerd]

accessors

De accessors zijn inderdaad in de vorm: setX() en getX(), maar amberAlert die nu ook actief meewerkt aan het project heeft tevens ondersteuning geschreven voor dynamic properties dus je kunt wel: $post->content = '...'; doen. Array-notatie wordt op dit moment alleen ondersteund via de import-methode. Jammer is namelijk dat je met arrays niet kan zeggen: $post->getRelatedComment(); en dergelijke, dat vond ik nu juist zo elegant aan de OO oplossing. Wat betreft find() heb je volgens mij deels een punt. Bij een grote resultset kan de performance eronder gaan lijden; je kunt echter:

a. een limit optie meegeven aan de find() methode
b. omdat het 'domme' queries zijn kan MySQL deze extreem snel verwerken (weet ik ook pas sinds kort, bezuiningen doormiddel van het schrijven van complexe queries schijnt dus niet zo verstandig te zijn).

Bedankt voor je feedback! Wat zou je verder graag in de ORM laag zien?

 

[Anotherhero]

Jammer is namelijk dat je met arrays niet kan zeggen: $post->getRelatedComment();

Ik bedoelde ook geen array van de "Beans" maken. Je zou ipv __get wat nu blijkbaar geimplementeerd is ook de interface ArrayAccess kunnen implementeren.

In plaats van de class te genereren kan men ook zelf de classes vooraf defineeren? Zodat je dus model specifieke functionaliteit als method's toe kan voegen?