Is there a blocker bug for this? At the very least it seems to break choosing storage by tag, right?
On Thu, Mar 7, 2013 at 4:03 AM, Prasanna Santhanam <t...@apache.org> wrote: > On Thu, Mar 07, 2013 at 02:00:08AM +0530, Ryan Dietrich wrote: >> A new column was added to storage_pool, called storage_provider_id. >> When trying to access a StoragePoolVO instance (when I go to attach >> a volume to a VM) I popped a null pointer. This may be related to >> CLOUDSTACK-1547, but I'm not sure yet. >> The bigger issue in my mind though, is the fact that the assert in >> GenericDaoBase wasn't tripped! (line 1683) >> assert (attr != null) : "How come I can't find " + >> meta.getCatalogName(index) + "." + meta.getColumnName(index); >> >> My questions are. >> >> Why doesn't the default startup for cloudstack "mvn -pl >> :cloud-client-ui jetty:run" enable asserts? (the -ea flag)? > > I don't know if maven-jetty can do this automatically. will check on > that. But you can -ea in your MAVEN_OPTS to turn it on. > >> Why in the world is SqlGenerator using STAR in it's queries? I've >> pasted the query it generated below. This new column isn't mapped >> as an attribute. >> SELECT storage_pool.* from storage_pool LEFT JOIN >> storage_pool_details ON storage_pool.id = >> storage_pool_details.pool_id WHERE storage_pool.removed is null and >> storage_pool.data_center_id = 1 and (storage_pool.pod_id = 1 or >> storage_pool.pod_id is null) and (storage_pool.cluster_id = 1 OR >> storage_pool.cluster_id IS NULL) AND >> (((storage_pool_details.name='bssan') AND >> (storage_pool_details.value='true'))) GROUP BY >> storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name) >> >= 1 > > I agree - *-ed queries are just bad. It's not from SqlGenerator I think, > the query is composed in StoragePoolDaoImpl. It's a good idea to > assert this and prevent execution of *-ed queries from SqlGenerator > though. Are you able to propose a fix of that nature? A jira ticket if > not - I'll see if that can be fixed. > > Thanks, > > -- > Prasanna.,
