A prop_values view is the cleanest solution. Any chance you can upgrade toPostgres? :) Failing that, you could probably make a new relationship type
for this "pull values from many different tables depending on a column valuein another table" relationship, but I'm not sure how general-purpose it'
On 5/3/06 7:41 PM, Guillermo Roditi wrote:
> SQL definitions are at the bottom if i am not clear enough
>
> yeah, i am basically trying to do a view, but myISAM doesnt support it [...]
>
> I baiscally want the different types of property vlues to be as transparent
> to the interface as possib
SQL definitions are at the bottom if i am not clear enoughyeah, i am basically trying to do a view, but myISAM doesnt support itbasically this is what i haveI have users, user properties, and user property types and user property values.
A user is straight forward;A user prop is a named pro
On 5/3/06 5:58 PM, Guillermo Roditi wrote:
> Normally I would just create an aggregator class that managed the dispatching
> of the right object types and queried all tables and merged the results
That sounds like a fine solution to me.
> but I'd like to make something that can more closely iterf
niice. Works perfectly now. I have another question too. I'm sorry if I am posting to the list too much, but I have been reading the docs, and I still have some questions kind of left over.I am trying to set up a class which will basically be an agregator of relationships. I however have no idea of
On 5/3/06, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
I have a table which includes a blob and a field for a hash of that blob.
I'd like to make atrigger that automatically updates the hash every time the
blob is changed, so i figured i would do it with a trigger. I figured the
best way to do it
