On Thu, Jun 21, 2012 at 06:38:09PM +0200, Petr Jakeš wrote:
> Hmmm.... Views, IMHO, are just SELECTS transformed to views. It means not
> special SQL digging is necessary.
Well. I did not understand the syntax of your view definition.
In particular, I do not understand the meaning of «hash». Is
it a keyword in some dialect of SQL? (I don't find it in postgresql.)
If it is a table name, what is then m/m1? Second question, what makes
sure that the id, presumably m.id, is unique for every record in the view?
I think I saw some warnings against using SQLObjects to represent
server side views, but if you say it works, it is worth a try.
> Anyway, for some really complex SELETS, direct SQL is the way to go.
I can live with that in some cases, but it is important for me to
preserve loose coupling in the object-oriented model.
However, the real challenge, whether the view is defined client
side or server side, is to construct the unique and immutable ID
which SQLObject requires. It would be useful to have both the
SQL and the python solution to that ...
Your code for reference:
CREATE VIEW HASH_VIEW (ID, OSOBY_ID, JMENO_1, JMENO_2, IBUTTON,
select m.id, deriv.osoby_id, deriv.jmeno_1, deriv.jmeno_2,
from hash m
select m1.osoby_id, p.jmeno_1, p.jmeno_2, p.ibutton, max(m1.t_stamp)
from hash m1
join osoby p on (p.id = m1.osoby_id)
group by 1,2,3,4)
as deriv (osoby_id, jmeno_1, jmeno_2, ibutton, t_stamp) on
m.osoby_id = deriv.osoby_id
where deriv.t_stamp = m.t_stamp;
:-- Hans Georg