Hi
Dne Wed, 12 Aug 2009 02:12:43 -0400
"Zeeshan M." <zeeshan.jp(a)gmail.com> napsal(a):
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had
"design flaws" as suggested by Marc Delisle, and other developers. Please
correct me if I am wrong, or you are referring to something else by
"configurable".
I mean table name, like Sebastian already has explained.
You should
really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for
SELECT I get errors. [1] Following line of code demonstrates how I am
implementing PMA_query_as_controluser:
return PMA_DBI_fetch_result(PMA_query_as_controluser($sql));
You need to add flags PMA_DBI_QUERY_STORE to query if you want to fetch
whole result at once.
I also tried to include:
/*
* Creates a $pma_usr_prefs pointer
*/
$pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being
remotely included in a standalone function:
*Fatal error*: Call to a member function fetchSettingValue() on a non-object
And what's reason for creating class and function of same name?
I think you could use similar way like we use for relation stuff.
--
Michal Čihař |
http://cihar.com |
http://blog.cihar.com