Leonel's suggestion worked but I had to set the key within headers
dictionary and column name within column lists of SQLTABLE to
'''GROUP_CONCAT("RISCHI"."rischio", \', \')'''
However, it seems to me that pyDal accepts SQL strings but it is SQLTABLE
that doesn't handle them as before. So I have two questions.
1) If pyDal regularly returns the rows of a select containing a SQL string,
why doesn't SQLTABLE - which should just serialize these in a view - accept
them?
2) since the problem is generated by the following line
tablemap = dict(((f.tablename, f.table) if isinstance(f, Field) else (f.
_table._tablename, f._table) for f in fieldmap.values()))
In the SQLTABLE class is it doable to apply the Leonel suggested code or
to make a fallback to the old working code when f._table is None ?
Thank you for your attention.
Il giorno giovedì 15 marzo 2018 16:02:32 UTC+1, Anthony ha scritto:
>
> On Thursday, March 15, 2018 at 7:59:42 AM UTC-4, Leonel Câmara wrote:
>>
>> I'm going to say it outright I don't think this should be supported.
>>
>> I don't think this should be considered a backwards compatibility
>> problem, because you're not using the DAL API you're just sending SQL in a
>> string.
>>
>
> Agreed, it's not strictly a backward compatibility issue. Therefore, we
> don't necessarily need to restore the old functionality exactly (i.e.,
> allow SQL strings to be passed to .select() and expect SQLTABLE to display
> the results), but it would be good to provide some means of achieving
> similar results.
>
>
>> from pydal.objects import Expression
>> dialect = db._adapter.dialect
>>
>> def group_concat(first, second, query_env={}):
>> return "GROUP_CONCAT(%s, '%s')" % (dialect.expand(first, query_env),
>> second)
>>
>> rischi_della_mansione = Expression(db, group_concat, db.RISCHI.id, ', ',
>> 'string')
>>
>>
>> We need to define that the proper way to put custom SQL mixed with DAL
>> code is using Expression and document how to use it. SQL in strings isn't
>> acceptable, for that you use executesql.
>>
>
> The above is not part of the DAL public API either, and it is a rather
> cumbersome way to add custom SQL to a select. So, rather than simply
> documenting the above, it would be better if we could come up with a
> simplified API for adding custom SQL expressions to both queries (i.e.,
> "WHERE" clauses) and selects. In the short term, I suppose we could
> document the above as a workaround, but I'm not sure we want to commit to
> that as a public API that must be supported indefinitely (we then lose the
> freedom to change any of those exposed internal implementation details).
>
> Anthony
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
