I think it is a good idea to simplify underlying model. Could we
additionally provide SQL views that groups only one variant and expose it
via REST point?
So clients will get the best of both worlds.
Not sure if H2 supports SQL views but there is a different way how to map
data there for sure.
Karel
On Wed, 7 May 2014 09:36:28 +0200
Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi all,
As we are working on implementing the new visual design for the console we
ran into something. Right now when you fetch a PushApplication from the rest
service everything is eager fetched including all variants for that
application but also all installations for all these variants.
Now in the old console these installations where only used to list the number
of installations on the ‘application details’ page next to the variant, for
the new console I’ve introduced a count ‘call’ to do the same so we no longer
need this eager fetch.
This count query is a bit hard as we have separated the association of the
variants per type so in order to have a count of the number of installations
we have to do x queries where ( x is the number of device types)
Example:
"select v.variantID, count(*) from PushApplication pa join pa.androidVariants
v join v.installations i "
+ "where pushApplicationID = :pushApplicationID and i.enabled
= true "
+ "group by v.variantID";
This query will give the total number of installations for each variant, but
only for android. So what I would like to suggest it to simplify the data
model and only have a relation with variants instead of one per type this
will also make the data model more extendable (when a new device type is
introduced the data model doesn’t have to change). If grouping of these
variants is needed clients will need to do it themselves.
WDYT
Erik Jan