[php+mysql] supplied argument not valid result resource

[Verwijderd]

Ik probeer de volgende query uit te voeren maar er gaat wat mis. Mysql geeft helaas geen errornr mee dus ik weet niet wat ik er mee moet.

PHP:

$query = 'SELECT * FROM `menu` WHERE `menu_link` = "ontwerp_concept"';
$row = mysql_fetch_object($query); // Dit is regel 7

Bovenstaande geeft de error: Warning: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in bla\bla\b_menu.inc.php on line 7

De tabel ziet er zo uit:


Bij het uitvoeren van de query in phpmyadmin gaat het overigens prima. I.p.v. "mysql_fetch_object" heb ik ook "mysql_fetch_array" en "mysql_fetch_row" geprobeerd, maar dit gaf de zelfde fout. Ook heb ik verschillende quotes geprobeerd ' ` ", maar helaas.

De query op deze manier gaf ook het zelfde resultaat:

code:

$sql = 'SELECT * FROM `menu` WHERE `menu_link` = CONVERT(_utf8 \'ontwerp_concept\' USING latin1) COLLATE latin1_general_ci';

[ Voor 3% gewijzigd door Verwijderd op 26-07-2007 02:28 . Reden: typo ]

[scorpie]

http://nz.php.net/mysql_fetch_object

zegt dat ie als argument een resource handler wil, en geen string...

edit: oftewel, dit moet wel werken:

PHP:

<?php
$query = mysql_query("SELECT * FROM `menu` WHERE `menu_link` = 'ontwerp_concept'");
$row = mysql_fetch_object($query); // Dit is regel 7
?>

mag ik misschien ook opmerken dat comments als "Dit is regel 7" je later denk ik niet veel gaan helpen bij het debuggen?

edit2:
(Internet hier in Nieuw Zeeland is traag )
Er staat zelfs notabene bij:

Parameters

result

The result resource that is being evaluated. This result comes from a call to mysql_query().

Volgende keer eerst koffie, dan coden (of bier, helpt ook wel )

[ Voor 86% gewijzigd door scorpie op 26-07-2007 02:16 ]

[Optix]

Verwijderd schreef op donderdag 26 juli 2007 @ 01:58:
Mysql geeft helaas geen errornr mee dus ik weet (niet) wat ik er mee moet.

Omdat je de query niet uitvoerd he

[Snake]

1: Zoals hier ^^, je moet een resource geven, geen query.
2: Je probeerde een string te selecteren, zet er dan ' ' rond.
3: Ik weet niet hoe je het ophaalt, misschien met $_GET of $_POST (de menulink), mag ik je dan even naar de http://be.php.net/pdo klasse wijzen, deze is eigenlijk stukken veiliger.
4: wil je nummering, doe dan

PHP:

$query = 'SELECT * FROM `menu` WHERE `menu_link` = "ontwerp_concept"';
$row = mysql_fetch_object($query); // Dit is regel 7 

, dan start die op regel 6, en is regel 7 regel 7 (kan je nog volgen? )
[code=php,6][/]

[Verwijderd]

scorpie schreef op donderdag 26 juli 2007 @ 02:10:
http://nz.php.net/mysql_fetch_object
zegt dat ie als argument een resource handler wil, en geen string...
edit: oftewel, dit moet wel werken:

PHP:

<?php
$query = mysql_query("SELECT * FROM `menu` WHERE `menu_link` = 'ontwerp_concept'");
$row = mysql_fetch_object($query); // Dit is regel 7
?>

Volgende keer eerst koffie, dan coden (of bier, helpt ook wel )

Zo letterlijk overgenomen werkt dit idd. Ik gebruik alleen een class voor het uitvoeren van de query en dan gaat het weer mis. Dan gaar het weer fout op regel 34 in de class.

Dit is dan de "echte" code:

PHP:

    $query = 'SELECT * FROM `menu` WHERE `menu_link` = \''.$vars[0].'\'';
    $mydb->query($query);
    $row = $mydb->fetch_object($query);

en dit de functie in de class:

PHP:

    function fetch_object($query) {     
        $array = array();
        while ($row = mysql_fetch_object( $query )) {     // Dit is regel 34
            if ($key) {
                $array[$row->$key] = $row;
            } else {
                $array[] = $row;
            }
        }
        mysql_free_result( $query );
        return $array;      
    }

Terwijl dit het wel weer doet:

PHP:

    $query = mysql_query("SELECT * FROM `menu` WHERE `menu_link` = '".$vars[0]."'");
    $row = mysql_fetch_object($query);

[Snake]

PHP:

   $query = 'SELECT * FROM `menu` WHERE `menu_link` = \''.$vars[0].'\'';
    $query = $mydb->query($query);
    $row = $mydb->fetch_object($query);

Kijk eens goed naar mijn en jouw 2de regel

Overigens, in je tweede lap code snap ik niet wat die $row->$key wilt...

[ Voor 15% gewijzigd door Snake op 26-07-2007 02:53 ]

[Verwijderd]

Snake schreef op donderdag 26 juli 2007 @ 02:52:

PHP:

   $query = 'SELECT * FROM `menu` WHERE `menu_link` = \''.$vars[0].'\'';
    $query = $mydb->query($query);
    $row = $mydb->fetch_object($query);

Kijk eens goed naar mijn en jouw 2de regel

Overigens, in je tweede lap code snap ik niet wat die $row->$key wilt...

Het verschil is volgend mij dat jij de query in regel 1 naar mysql stuurt en in regel 2 uitvoerd. En ik stop de query eerst in een var, zodat ik hem nog kan "echo-en" en daarna stuur ik um naar mysql en voer ik de fetch uit.

Misschien is dit stukje handig nog:

PHP:

    function query($query) {
        $query = mysql_query($query) or die(mysql_error());
        return $query;
    }

Die class heb ik overgenomen van iemand. Maar ik denk dat die $row->$key een [0] en [1] enz aanmaakt bij een array. i.p.v. [veld1], [veld2] enz. Dat weet ik niet zeker.

Ik ga nu pitten. Kan dus pas over paar uur weer reageren.

[ Voor 4% gewijzigd door Verwijderd op 26-07-2007 03:13 . Reden: typo ]

[Snake]

Verwijderd schreef op donderdag 26 juli 2007 @ 03:08:
[...]


Het verschil is volgend mij dat jij de query in regel 1 naar mysql stuurt en in regel 2 uitvoerd. En ik stop de query eerst in een var, zodat ik hem nog kan "echo-en" en daarna stuur ik um naar mysql en voer ik de fetch uit.

Misschien is dit stukje handig nog:

PHP:

    function query($query) {
        $query = mysql_query($query) or die(mysql_error());
        return $query;
    }

Die class heb ik overgenomen van iemand. Maar ik denk dat die $row->$key een [0] en [1] enz aanmaakt bij een array. i.p.v. [veld1], [veld2] enz. Dat weet ik niet zeker.

Ik ga nu pitten. Kan dus pas over paar uur weer reageren.

Kijk, in je klasse return je $query, dewelke een mysql resource is, die je dan weer gebruikt in fetch_object.

Het was allemaal veel duidelijker als PHP ook je verplichtje types mee te geven. Maar we zijn lui voor iets blijkbaar.

En niet gaan slapen, da's tijdverlies.

[scorpie]

Verwijderd schreef op donderdag 26 juli 2007 @ 03:08:
[...]


Het verschil is volgend mij dat jij de query in regel 1 naar mysql stuurt en in regel 2 uitvoerd. En ik stop de query eerst in een var, zodat ik hem nog kan "echo-en" en daarna stuur ik um naar mysql en voer ik de fetch uit.

Misschien is dit stukje handig nog:

PHP:

    function query($query) {
        $query = mysql_query($query) or die(mysql_error());
        return $query;
    }

Die class heb ik overgenomen van iemand. Maar ik denk dat die $row->$key een [0] en [1] enz aanmaakt bij een array. i.p.v. [veld1], [veld2] enz. Dat weet ik niet zeker.

Ik ga nu pitten. Kan dus pas over paar uur weer reageren.

Om eerlijk te zijn vind ik het niet duidelijk, je maakt het jezelf onnodig moeilijk. Kijk eens naar je functie "query". Wat return je nu? De variable "query" die je als argument binnenkrijgt of die je erna toewijst? Als je nou een klein verschil aanbrengt, zoals het argument veranderen in "qry" ofzo, is dat voor jezelf veel duidelijker. Ongeacht of PHP, welke echt uberranzige code accepteert, het wel allemaal aankan. Die ene extra variable past vast nog wel in je memory. En later gebruik je die variable "query" overigens weer, terwijl het dan dus een resource handler is.. talking about duidelijke variablenames he?

[Verwijderd]

Snake schreef op donderdag 26 juli 2007 @ 03:15:
[...]

Kijk, in je klasse return je $query, dewelke een mysql resource is, die je dan weer gebruikt in fetch_object.

Het was allemaal veel duidelijker als PHP ook je verplichtje types mee te geven. Maar we zijn lui voor iets blijkbaar.

En niet gaan slapen, da's tijdverlies.

Dat stukje over die resource gaat me (nu) boven mn slaapmuts.

En je laatste zin vind ik erg goed.

[Verwijderd]

Snake schreef op donderdag 26 juli 2007 @ 02:42:
even naar de http://be.php.net/pdo klasse wijzen, deze is eigenlijk stukken veiliger.

Alleen PDO maakt de boel niet veilig hoor, je moet em wel juist gebruiken anders is het nog niet veilig.

Het is ook niet zo nuttig PDO te gebruiken als je ook gewoon mysqli kunt gebruiken, die is toch net een tandje sneller en een stuk functioneler wanneer het aankomt op MySQL.

(Beide pas vanaf versie 5 beschikbaar, zit je vast op PHP4 heb je pech)

@TS:

Er is een verschil tussen je query (een string) en het resultaat (die je beter in bijvoorbeeld $result kunt zetten en niet in $query), het resultaat is namelijk een resource waarmee je ook daadwerkelijk kan. $query is gewoon een string en doet helemaal niets, sterker nog je kunt de query ook direct in je functie gooien dan hoef je er helemaal geen variabele voor te gebruiken.

[ Voor 29% gewijzigd door Verwijderd op 26-07-2007 04:24 ]

[Equator]

Dus:

Of zo

PHP:

$query = "SELECT * FROM mijntabel";
$result = mysql_query($query) or custom_error_handler(mysql_error());
$iets = mysql_fetch_object($result);

of nog korter, maar minder leesbaar:

PHP:

$query = "SELECT * FROM mijntabel";
$iets = mysql_fetch_object(mysql_query($query));

Maar in het laatste voorbeeld is het aan te raden om dan een eigen query functie te gebruiken zodat je eventuele errors af kan vangen/displayen.

Edit: Naar aanleiding van hieronder: enigzins aangepast..

[ Voor 8% gewijzigd door Equator op 27-07-2007 08:57 ]

[Verwijderd]

or die(mysql_error()); is geen goed idee in productieomgevingen, het beste is gewoon een error te triggeren en ervoor te zorgen dat er een goede foutafhandeling is.

Mocht je dan een fout maken waardoor een exploit mogelijk is heb je in ieder geval nog dat kleine beetje extra security through obscurity en ligt niet gelijk het antwoord klaar voor iedere scriptkiddie.

[Equator]

True, het was maar ook een snelle voorbeeld code. die() gebruik ik wat dat betreft nooit.

[Verwijderd]

I know, maar het probleem is dat veel voorbeeld code dat op die manier doet, mensen leren het dan aan en wanneer ze aan het grotere werk beginnen doen ze het nog steeds met alle gevolgen van dien.

Dus ik denk ik zeg het maar even

[Verwijderd]

Ik wete niet meer waar het probleem lag, maar dit is mijn code en het werkt.

PHP:

    $query = $mydb->query('SELECT * FROM `menu` WHERE `menu_master` = '.$m_active.'');
    $row = $mydb->fetch_object($query);

Bedankt voor de hulp.

[FragFrog]

Waarom gebruik je uberhaupt die database class? Van wat ik ervan kan zien is'ie maar knap slecht geschreven; als voorbeeld is hierboven al genoemd dat'ie die() gebruikt in geval van een error, maar ook het feit dat je zelf de resource handle moet kopieeren (nouja, of referencen, maar same difference) is imho nogal zwak. if ($key) doet daarnaast voor zover ik kan zien ook niks, of je moet niet de gehele code gepaste hebben.

Sluit me dan ook aan bij Snake ea dat je beter PDO kan gebruiken, of bijvoorbeeld MDB2

[Verwijderd]

Wat is er mis met mysqli dan?

Database Abstraction Layers Must Die!

[ Voor 73% gewijzigd door Verwijderd op 29-07-2007 02:07 ]

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 02:07:
Wat is er mis met mysqli dan?

Het feit dat niet iedereen MySQL gebruikt misschien?

[Verwijderd]

FragFrog schreef op zondag 29 juli 2007 @ 02:17:
[...]

Het feit dat niet iedereen MySQL gebruikt misschien?

Je bent toch de TS advies aan het geven? Hij gebruikt MySQL (heb ik zo'n vermoeden )

[Snake]

Verwijderd schreef op zondag 29 juli 2007 @ 02:07:
Wat is er mis met mysqli dan?

Database Abstraction Layers Must Die!

Beetje mierengeneuk dat artikel... Inderdaad, switchen van database is helemaal niet gemakkelijk, maar waarom EN de code om alles uit te voeren EN alle query's aanpassen, ipv gewoon 1 klasse te schrijven/gebruiken, die aanpassen, en dan alle query's gaan aanpassen (wat niet zoveel kan zijn, syntaxverschillen zijn minimaal, en tabellen creëer je toch niet direct in php).

[Verwijderd]

Omdat het gewoon niet handig is als je MySQL gebruikt een hele tussenlaag erbij te stoppen terwijl er een prima library bestaat welke dezelfde functionaliteiten en meer bevat en voor 100% gericht is op de database die je gebruikt.

Je krijgt een betere performance, de functies en werking van de library is afgestemd op de database die je gaat gebruiken en het zogenaamde voordeel van een algemene tussenlaag bestaat helemaal niet omdat switchen toch een pain in the ass blijft.

(En dat artikel staat voor een grote stroming mensen die het daar mee eens zijn, de database access abstraction layers zoals die bestaan voor PHP zijn gewoon niet handig om te gebruiken omdat ze geen voordeel bieden tov de gerichte libraries)

[ Voor 20% gewijzigd door Verwijderd op 29-07-2007 02:35 ]

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 02:18:
Je bent toch de TS advies aan het geven? Hij gebruikt MySQL (heb ik zo'n vermoeden )

In dit geval wel ja. Wie zegt dat'ie niet voor een ander project MSSQL gaat gebruiken, of een ODBC connectie, just to name some? In zo'n geval moet'ie weer op zoek naar een andere goede DBAL (vooropgesteld dat'ie die wil gebruiken, wat uit zijn voorbeeldcode wel zo lijkt te zijn). Ik raad mensen liever aan een generieke tool te gebruiken dan eentje die nauwelijks voordelen heeft en alleen in een specifiek geval toepasbaar is. Sowieso is MySQLi standaard niet aanwezig op windows platformen, kun je er niet vanuit gaan dat het beschikbaar is op een random webhost, etc.

In PHP geldt meer dan in welke taal dan ook dat er vaak tientallen verschillende manieren zijn om voor elkaar te krijgen wat je wilt. In mijn opinie kenmerkt een goede PHP coder zich door de meest geschikte methode voor elk specifiek probleem te gebruiken. Ik ben het met je eens dat in dit geval mysqli, indien beschikbaar, een van de beste opties is, maar ik ga niet een specifieke methode aanraden aan iemand die op mij overkomt als relatief onervaren als er ook uitstekende generieke manieren zijn.

En ja, er is een hele goede discussie mogelijk over het al dan niet gebruiken van DBAL's. Zelf gebruik ik doorgaans een database class die ik in de loop der jaren ontwikkelt en verfijnt heb en die qua functionaliteit tussen een DBAL en een library inligt - datgene wat de schrijver van je artikel ook lijkt te doen. Maar als je geen behoefte hebt om het wiel opnieuw uit te vinden is iets als MDB2 erg geschikt.

[ Voor 13% gewijzigd door FragFrog op 29-07-2007 02:41 ]

[Verwijderd]

FragFrog schreef op zondag 29 juli 2007 @ 02:36:
[...]

In dit geval wel ja. Wie zegt dat'ie niet voor een ander project MSSQL gaat gebruiken, of een ODBC connectie, just to name some? In zo'n geval moet'ie weer op zoek naar een andere goede DBAL (vooropgesteld dat'ie die wil gebruiken, wat uit zijn voorbeeldcode wel zo lijkt te zijn). Ik raad mensen liever aan een generieke tool te gebruiken dan eentje die nauwelijks voordelen heeft en alleen in een specifiek geval toepasbaar is.

Waarom is dat beter? Ik denk dat het beter is als ie een andere database gaat gebruiken ie zich daar eerst in verdiept zodat er tenminste ook iets fatsoenlijks uit komt.

Een beetje aanklooien met een database is leuk, maar wil je het echte werk doen dan zal je toch moeten weten waar je mee bezig bent, volledig gebruik moeten maken van de mogelijkheden die de specifieke database biedt en de code/queries/database opzet moeten optimaliseren.

Heel leuk als je de generieke library kunt gebruiken, maar vervolgens een hoop fouten maakt omdat je eigenlijk niets weet van de database waarmee je werkt.

Sowieso is MySQLi standaard niet aanwezig op windows platformen, kun je er niet vanuit gaan dat het beschikbaar is op een random webhost, etc.

Non-argument, hetzelfde geldt voor de andere genoemde libs.

In PHP geldt meer dan in welke taal dan ook dat er vaak tientallen verschillende manieren zijn om voor elkaar te krijgen wat je wilt. In mijn opinie kenmerkt een goede PHP coder zich door de meest geschikte methode voor elk specifiek probleem te gebruiken. Ik ben het met je eens dat in dit geval mysqli, indien beschikbaar, een van de beste opties is, maar ik ga niet een specifieke methode aanraden aan iemand die op mij overkomt als relatief onervaren als er ook uitstekende generieke manieren zijn.

Je hebt helemaal gelijk, maar ik ben het niet met je eens

Het is denk ik een beetje een judgement call hoe je iemand advies geeft, ik denk dat er in dit geval weinig voor/nadelen zijn van een specifieke oplossing tov een generieke oplossing en andersom. In dat geval is het dus netjes de TS te wijzen op beide oplossingen ipv alleen maar een generieke oplossing te noemen terwijl de TS misschien juist zoekt naar een gerichte oplossing omdat ie de komende tijd toch alleen met MySQL gaat werken. (En bij een volgende database gewoon het leertraject weer in gaat om die te leren kennen)

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 02:41:
Non-argument, hetzelfde geldt voor de andere genoemde libs.

Niet helemaal waar. MDB2 vereist voor zover ik weet enkel standaart PHP functionaliteit, en PDO is standaart wel meegecompileert vanaf PHP5. Natuurlijk, die laatste moet je wel activeren in je php.ini, maar dat is een stuk simpeler dan 'm er nog eens bij in compilen.

Wat betrefd wel / niet wijzen op specifieke methodes: ben bang dat we daar niet uit gaan komen nee Ervaring leert mij dat mensen liever iets algemeens leren dan elke keer opnieuw het traject ingaan, en hoewel dat wel beter is in principe help je iemand er simpelweg niet mee. Als iemand fouten maakt in de trent van niet mysql_query aanroepen en dan vragen waarom mysql_fetch_object niet werkt ga ik er vanuit dat hij niet enorm veel belangstelling heeft bij het leren van PHP - immers, dan had'ie wel de handleiding doorgespit waarin het vrij duidelijk uitgelegd staat. Er zijn genoeg mensen die PHP gebruiken om af en toe iets in elkaar te plempen wat werkt en waar verder niet meer naar gekeken hoeft te worden, die zijn prima af met een algmene DBAL als je't mij vraagt

[Verwijderd]

Tjah, beter af met een algemene DBAL en dan zich afvragen waarom alles zo traag gaat...

Je zal je toch moeten verdiepen in het spul, anders gaat het sowieso niet werken.

Maar wat je zegt over MDB2 klopt niet, dat is een PEAR package en dus moet je PEAR hebben (niet echt standaard, maar wel te regelen).

PDO zit ook niet standaard in PHP en al zeker niet vanaf 5.0. In 5.0 was ie alleen als PECL beschikbaar.

Vanaf 5.1 moet je em gewoon handmatig meecompileren met de volgende flags: (dan gelijk met sqlite erbij zodat je er in ieder geval iets mee kunt, zlib is ook nodig)

--with-zlib --enable-pdo=shared --with-pdo-sqlite=shared --with-sqlite=shared

Je kunt em ook als .so inladen.

Onder Windows moet je even de DLL inladen.

Maar met alleen PDO ben je er natuurlijk nog niet, PDO kan zelf namelijk geen databases aanspreken, daar zijn weer aparte packages voor nodig afhankelijk van de database die je wilt gaan gebruiken.

Je kunt die extra database packages ofwel direct meecompileren met extra flags ofwel inladen als .so of .dll bestanden (afhankelijk of je onder Windows zit of niet).

Om mysqli aan de praat te krijgen heb je 1 flag nodig of kun je 1 .so of .dll inladen (weet niet zeker of er een .so van is, maar zal wel).

Alle genoemde libraries zijn dus niet standaard en ongeveer even moeilijk of makkelijk om te installeren waarbij PDO het moeilijkste is en mysqli het gemakkelijkste.

Het argument dat PDO op een of andere manier meer standaard zou zijn is dus een non-argument

En wijs in het gevolg gewoon mensen op meerdere mogelijkheden, zowel specifiek als non-specifiek, dan kunnen mensen zelf kiezen ipv blind op jou te vertrouwen. Niet dat jij niet te vertrouwen bent, maar mensen aanleren blind op andere mensen te vertrouwen is nooit handig

[ Voor 8% gewijzigd door Verwijderd op 29-07-2007 03:19 ]

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 03:16:
Tjah, beter af met een algemene DBAL en dan zich afvragen waarom alles zo traag gaat...

Je zal je toch moeten verdiepen in het spul, anders gaat het sowieso niet werken.

Maar wat je zegt over MDB2 klopt niet, dat is een PEAR package en dus moet je PEAR hebben (niet echt standaard, maar wel te regelen).

Hoe kom je erbij dat een DBAL vertragend moet werken? Een goede DBAL zal juist connecties open houden, eventueel results cachen etc en daardoor zeker niet vertragend werken. Verdiep je zelf eens in het spul!

Wat betrefd installeren: als je op een webhost moet werken kun je doorgaans wel pear installeren aangezien dat in feite gewoon een stel PHP scripts is. Als je geen toegang hebt tot php.ini (zoals bijna altijd het geval is met shared hosting) is MDB2 daarom afaik juist de enige van de genoemde 3 opties die wel toegankelijk is. Niet geheel toevallig ook degene die ik gelinkt heb in mijn eerste post

En ja, je kan natuurlijk mensen tientallen opties geven. Ik gaf er in mijn post 2, als iemand echt geinteresseerd is en meer wil weten gaat'ie zelf wel op zoek naar alternatieven. Mensen niet leren blind vertrouwen ben ik volledig met je eens, maar mensen alles voorkauwen is minstens net zo slecht En iets met dat we gruwelijk offtopic aan het raken zijn

[Verwijderd]

FragFrog schreef op zondag 29 juli 2007 @ 04:08:
[...]

Hoe kom je erbij dat een DBAL vertragend moet werken? Een goede DBAL zal juist connecties open houden, eventueel results cachen etc en daardoor zeker niet vertragend werken. Verdiep je zelf eens in het spul!

No worries, ik weet er genoeg van.

Een DBAL voegt per definitie overhead toe omdat het een extra tussenstap is.

Connecties openhouden, cachen etc kan de mysqli library ook prima, de mysqli library is qua functionaliteit (bij gebruik van MySQL natuurlijk) beter als PDO en MDB2 omdat het wel volledig van alle functionaliteiten van MySQL gebruik kan maken waar de andere libs dit niet kunnen.

Wat betrefd installeren: als je op een webhost moet werken kun je doorgaans wel pear installeren aangezien dat in feite gewoon een stel PHP scripts is. Als je geen toegang hebt tot php.ini (zoals bijna altijd het geval is met shared hosting) is MDB2 daarom afaik juist de enige van de genoemde 3 opties die wel toegankelijk is. Niet geheel toevallig ook degene die ik gelinkt heb in mijn eerste post

Klopt, maar PEAR voegt heel erg veel overhead toe, daarnaast is het nogal wat wat je moet installeren en voor de gemiddelde gebruiker is dat allemaal niet zo eenvoudig.

Daarnaast denk ik dat als je een webhost hebt die kwalitatief genoeg is om PHP 5.1 te draaien dat PDO met MySQL en mysqli ook gewoon geinstalleerd staan. Anders moet je een andere webhost hebben

En ja, je kan natuurlijk mensen tientallen opties geven. Ik gaf er in mijn post 2, als iemand echt geinteresseerd is en meer wil weten gaat'ie zelf wel op zoek naar alternatieven. Mensen niet leren blind vertrouwen ben ik volledig met je eens, maar mensen alles voorkauwen is minstens net zo slecht En iets met dat we gruwelijk offtopic aan het raken zijn

Je gaf inderdaad 2 opties, maar 2 opties die in feite 2 kanten van dezelfde munt waren. Geef em dan op z'n minst nog een echt alternatief

Het is inderdaad behoorlijk offtopic, om nog iets verder offtopic te gaan: Zijn jouw d's en t's altijd zo slecht of heb je teveel gezopen?

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 04:15:
Een DBAL voegt per definitie overhead toe omdat het een extra tussenstap is.

Connecties openhouden, cachen etc kan de mysqli library ook prima, de mysqli library is qua functionaliteit (bij gebruik van MySQL natuurlijk) beter als PDO en MDB2 omdat het wel volledig van alle functionaliteiten van MySQL gebruik kan maken waar de andere libs dit niet kunnen.

Natuurlijk, maar dat onderstreept alleen maar mijn punt dat DBAL's niet vertragend hoeven te werken he

Klopt, maar PEAR voegt heel erg veel overhead toe, daarnaast is het nogal wat wat je moet installeren en voor de gemiddelde gebruiker is dat allemaal niet zo eenvoudig.

Daarnaast denk ik dat als je een webhost hebt die kwalitatief genoeg is om PHP 5.1 te draaien dat PDO met MySQL en mysqli ook gewoon geinstalleerd staan. Anders moet je een andere webhost hebben

Niet iedereen heeft helaas die luxe. Voor zover ik zie werkt MDB2 ook gewoon met PHP 4.3 wat nog maar al te veel gebruikt wordt, het zou niet voor het eerst zijn dat iemand hier een topic opent met iets wat niet werkt om de simpele reden dat z'n webhost het niet toestaat

Je gaf inderdaad 2 opties, maar 2 opties die in feite 2 kanten van dezelfde munt waren. Geef em dan op z'n minst nog een echt alternatief

Het is inderdaad behoorlijk offtopic, om nog iets verder offtopic te gaan: Zijn jouw d's en t's altijd zo slecht of heb je teveel gezopen?

Ik prefereer de generieke munt, soit, voor specifieke oplossingen zijn er altijd wel anderen die gaan zeuren

En ja, mijn d's en t's zijn altijd zo slecht, als ik er hard op let wordt't wel beter maar 't is 4:18am hier en ik ben niet helemaal wakker meer

[Verwijderd]

FragFrog schreef op zondag 29 juli 2007 @ 04:21:
[...]

Natuurlijk, maar dat onderstreept alleen maar mijn punt dat DBAL's niet vertragend hoeven te werken he

Noujah het is natuurlijk ook maar geneuzel in de marge, maar dan nog is het niet handig expres te kiezen voor een oplossing die minder kan, een voordeel heeft dat eigenlijk niet bestaat en ook nog eens in de potentie vertragend is.

Een generieke DBAL moet altijd een generieke invoer vertalen in een non-generieke uitvoer naar de database toe, die vertaalslag zal per definitie overhead introduceren. Nu hoeft die vertaalslag niet groot te zijn en de overhead relatief gezien klein zijn tov het werk wat verzet moet worden, het is toch altijd aanwezig.

Via trucjes (cache, open verbindingen etc) kan een DBAL een performance boost opleveren, maar enkel als de achterliggende DB hier ook ondersteuning voor heeft. In het geval van MySQL is dit zo, maar aangezien de mysqli library alles kan wat MySQL kan heeft deze hier ook goede ondersteuning voor. Die winst heb je dus niet echt waardoor het in potentie trager werkt. (Al is het maar minimaal)

Niet iedereen heeft helaas die luxe. Voor zover ik zie werkt MDB2 ook gewoon met PHP 4.3 wat nog maar al te veel gebruikt wordt, het zou niet voor het eerst zijn dat iemand hier een topic opent met iets wat niet werkt om de simpele reden dat z'n webhost het niet toestaat

Klopt, PEAR werkt ook op oudere versies en je moet een webhost hebben die meewerkt. Maar om nu maar een oplossing met allerlei nadelen te noemen alleen omdat de TS misschien een rothost heeft. Als je em een goede oplossing geeft en hij zegt dat z'n host dat niet doet, dan zeg je em toch dat ie een andere host moet hebben?

Daarnaast moet PHP4 dood, iedereen in de wereld werkt eraan om van die oude crap af te komen en einde dit jaar gaat ie met pensioen dus vooral PHP5 oplossingen aanraden.

Ik prefereer de generieke munt, soit, voor specifieke oplossingen zijn er altijd wel anderen die gaan zeuren

Tjah, daarom altijd meerdere alternatieven presenteren. Dat jij een preferentie hebt is prima en dat kun je gerust melden, maar dat is geen reden om andere alternatieven dan maar niet te noemen. Er zijn meerdere wegen naar Rome

Het grappige is dat vroeger bij vragen over PHP en databases men altijd gelijk riep, je moet MySQL en de mysql library gebruiken. Nu met PHP5 roept iedereen ineens om een DBAL te gebruiken, maar heel weinig mensen weten eigenlijk waarom ze dat roepen.

Het is beter zeggen ze dan... mjah in mijn ogen (en heeeeel veel mensen met mij) is dat gewoon echt niet het geval. Je hebt meer overhead met geen enkele voordelen, daarnaast is er een hele mooie native library. Gebruik dan gewoon de native library of kom met goede redenen voor een DBAL.

En ja, mijn d's en t's zijn altijd zo slecht, als ik er hard op let wordt't wel beter maar 't is 4:18am hier en ik ben niet helemaal wakker meer

Misschien tijd om te gaan slapen dan?

[FragFrog]

Verwijderd schreef op zondag 29 juli 2007 @ 04:31:
Het grappige is dat vroeger bij vragen over PHP en databases men altijd gelijk riep, je moet MySQL en de mysql library gebruiken. Nu met PHP5 roept iedereen ineens om een DBAL te gebruiken, maar heel weinig mensen weten eigenlijk waarom ze dat roepen.

Het is beter zeggen ze dan... mjah in mijn ogen (en heeeeel veel mensen met mij) is dat gewoon echt niet het geval. Je hebt meer overhead met geen enkele voordelen, daarnaast is er een hele mooie native library. Gebruik dan gewoon de native library of kom met goede redenen voor een DBAL.

Tja, je hebt DBAL's en je hebt DBAL's

Je kan kiezen voor een echte abstractielaag die inderdaad alle calls herschrijft zodat je zonder moeite kan switchen tussen DB's en in zo'n geval ben ik het eigenlijk ook wel met je eens dat het nut gering dan wel niet aanwezig is - hoe vaak switch je tenslotte van database halverwege je applicatie

Echter, als je een DBAL hebt die meer een database factory pattern is kun je sinds PHP5 gebruik maken van exception handlers om een enorm krachtige tool te creeeren om altijd op eenzelfde wijze databases aan te spreken. In mijn ervaring bespaart het je een hele berg code schrijven en worden je applicaties er een stuk netter door, om nog maar te zwijgen over het feit dat je veel simpeler connectie-gegevens kan aanpassen of query-statistics kan bijhouden.

En ja, het is wel een beetje een hype aan het worden, net als OOP in PHP. Er zijn genoeg situaties waarin dat helemaal niet nuttig is, maar toch zie je iedereen het altijd aanraden Zoals ik in een van m'n eerste posts al zei: laat de experts fijn de beste, specifieke methode gebruiken, daar zijn ze tenslotte expert voor, en geef diegenen die net beginnen een algemene tool die altijd werkt - wellicht niet altijd even efficient, maar dat hoeft doorgaans ook helemaal niet zo nodig

Overigens was het weglaten van mysqli niet een bewuste keuze van mij hoor, had er simpelweg niet aan gedacht Ik schrijf geregeld open source applicaties, op een gegeven moment had ik een erg uitgebreid pakket geschreven wat gebruik maakte van een MSSQL server. Na de eerste beta bestond ongeveer tweederde van de reacties uit de vraag waarom mssql_connect het niet deed, ondanks dat ik in de install guide netjes gezet had dat ze de mssql functies in hun php.ini moesten activeren. Daarna alles omgeschreven om ODBC functies te gebruiken en dat werkte wel gewoon (ging hier om een website bij een gameserver die die ODBC connecties ook vereiste, dus die waren wel altijd aanwezig). Als je eenmaal een paar duizend regels code hebt lopen doorzoeken word je wat huiverig met het gebruik van niet-standaard werkende functies

offtopic:
Hoe lang zou het nog duren voor een modje langs komt met de melding dat we wel erg offtopic bezig zijn denk je?