Hi
Dne Wed, 12 Aug 2009 02:12:43 -0400 "Zeeshan M." zeeshan.jp@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.