Re: [binarycloud-dev] QueryManager / Standards

[Alex B. <en...@tu...>]

> Hi Alex,
> 
>>> So we should use indexed array for the result retrieving only.
>>> I'm not surehow this will fit with EntityManager (I briefly looked over
> the
>>> code and saw that by doing queries the $headers switch is turned on) but
> if it > > really needs that a mapping could be done in EntityManager not in
>>> QueryManager.
>> I would almost prefer to standardize db field names rather than
>> avoid using array keys, which are helpful for coding and debugging.


> Thats another option if the portability is guaranteed (nothing is
> truncated).
> But what if the db system changes its behaviour in a new versions?
> Everything has to be fixed. For debugging and code readability it's nice.

My point is that if we establish fairly restrictive standards about table
and field naming, we can get around those problems and ensure compatibility
between oracle, mySQL, and Postgres:

-table names * field names no longer than 32 chars
-all field and table names in CAPS

for example.

> Another option to get around this at QueryManager level could be an
> additional option field within the query statement e.g.:
> 
> $query = array(
> 'QUERY' =>
>   "SELECT VeryLongColumThatMightBeTruncated, ".
>   "anotherVeryLongColThatIsDefenetlyTruncated ".
>   "FROM tablewithverylongfieldnames WHERE foo = ?",
> 'ARGTYPES' => array('integer'),
> 'FIELDNAMES' => array('Name1','Nam2');
> );
> 
> Respective for the XML complement. So QueryManager can loop over the indexed
> arrays and generate an asoc array like:
> 
> $buffer[rownumber] = array(
>   "Name1" => Datafromverlongcolumn1,
>   "Name" => Datafromverylongcolumn2
> );
> 
> So we do not have the truncation problem but maybe a bit less performance
> and a bit more typing in this mode of operation.
> 
> Additionally we should do a naming convetion for tables/fields. Then we are
> 100%save ;-)

Re: the above, I'd prefer to have something that works with a standard,
instead of trying to build code that works with 'everything'.

I'm not saying QueryManager should process incoming queries (like
strtoupper) but I think we should standardize those names elsewhere in the
system.

_a



> 
>>> STORED QUERIES:
>>> QueryManager does have the abiliy to load stored queries. This
>> is used in
>>> EntityManager to load queries related to entities.  But there
>> might be the
>>> need to load user queries for one page call. My proposal is to
>> use the query
>>> load system on init, optionally of course. So we could have a
>> syntax like
>>> this
>>> 
>>> <database>
>>> <mcrypt>true</mrypt>
>>> ..
>>> <queries>
>>> <query>user.db.qry.UserQueriesFoo</query>
>>> <query>user.db.qry.UserQueryBar</query>
>>> </queries>
>>> 
>>> On Init the file user.db.qry.UserQueriesFoo is importet and the
>> queries are
>>> added to the queryList.  The user then does have the abiliy to
>> execute his
>>> querys directly: qm->DoQuery("QRY_USER_MYQUERYNAME").
>> 
> 
>> Why here? (I.e. in init, so early) why shouldn't query loading be the
>> responsibility of the code that needs the query?
> Hmm. If I have a page and I want to load a set of queries that are used by
> some or all modules of this page. I load the query-set at init time and the
> modules do not have to care about query loading. On the other hand the
> module could load the query passed by a parameter "user.mod.foo.Queries".
> Hmmm....
> 
> [query xml format]
>> I like the format above, nice n' clean :)
> Jepp. I think I'll do some experiments with that. And also with the query
> loading stuff.
> 
> Andi
> 
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>