----- "Raymond Mancy" <rmancy(a)redhat.com> wrote:
From: "Raymond Mancy" <rmancy(a)redhat.com>
To: "Marian Csontos" <mcsontos(a)redhat.com>
Cc: Beaker-devel(a)lists.fedorahosted.org
Sent: Monday, November 16, 2009 9:59:33 AM GMT +10:00 Brisbane
Subject: Re: [Beaker-devel] Ticket 55
----- Original Message -----
From: "Marian Csontos" <mcsontos(a)redhat.com>
To: Beaker-devel(a)lists.fedorahosted.org
Cc: "Raymond Mancy" <rmancy(a)redhat.com>
Sent: Wednesday, November 11, 2009 4:52:02 PM GMT +10:00 Brisbane
Subject: Re: [Beaker-devel] Ticket 55
Rejected by list first time...
> Hi Raymond,
> We can find out the type of key_value as well as key's id at query
> form creation time.
> IMO, this would render key_table unnecessary in all joins.
> We could even cache the form itself...
>
This is correct. At the moment though the relationships (i.e the table
column that the Key/Value points to) are defined before form
submission. This has
never been a problem up until now. I'm in the process of making an
exception to this rule...
Sorry, I just re-read your post Marian. We _can't_ find out the type of key_value at
form creation time,
Because the key_id that we are searching on is not determined until form submission, and
thus the type of key_value is not determined until form submission.
This is because Key/Value data that we search on can come from two different tables, as we
know.
This would be different if we were searing on Key/ValueString and Key/ValueInt, as each
selection would only represent a value from a single table, key_value_string and
key_value_int respectively.
Raymond
> I believe the next thing required is index on key_value_{int,string}
> tables: (key_id, value, system_id)this is necessary as we are
looking
> for key's with certain values (==) or in certain range and these are
> the most common operations and the key_value_* tables are out
largest.
> However, this is enough for separate Ticket.
>
> I made some experiments with RHTS and indexing fields boosted
> performance in order of magnitudes -
>
https://engineering.redhat.com/rt3/Ticket/Display.html?id=49438
> I believe Beaker would benefit from indexing as well.
I actually had no idea how big these tables were on the live system.
On my dev environment I have a handful of entries in these tables :-P
Creating an index on the key_id and value could very well help
things.
Cheers
Raymond
>
> If you are the DB man we are looking for it would be great!
>
> Cheers,
>
> -- Marian
>
>
> On 11/10/2009 10:32 PM, Raymond Mancy wrote:
>> ----- Original Message -----
>> From: "Bill Peck"<bpeck(a)redhat.com>
>> To: "Raymond Mancy"<rmancy(a)redhat.com>, "List for the
development
of
>> the Beaker project"<beaker-devel(a)lists.fedorahosted.org>
>> Sent: Wednesday, November 11, 2009 5:22:43 AM GMT +10:00 Brisbane
>> Subject: Ticket 55
>>
>>
>> Hi Raymond,
>>
>> I checked out ticket55 branch and tried it out. Couple
observations..
>>
>> 1) can we have it hide the Keyvalue pull down when Key/Value is
not
>> selected? Hide the pull down and the title as well. :-)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> I was perplexed because I had already put this in...I just did a
diff
>> though and realised I had forgotten to commit the template file.
>> That's done now, and it should be displaying the correct behaviour
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 2) the composite Key_Value_String / Key_Value_Int causes a serious
>> performance issue.
>>
>> It preloads every Value for every key.. so the following code took
over
>> 2 minutes on my laptop..
>>
>> @classmethod
>> def get_all_keys(cls):
>> all_keys = cls.query()
>> return [key.key_name for key in all_keys]
>>
>> I looked to see if there was some way to delay the loading but I
>> couldn't find any. Can you make the code work without the
composite?
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Hmm, possibly I can get it to work without the composite. I'm not
>> sure exactly how, but either way, we can't live with that kind of
>> performance hit.
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> p.s. - reply to the beaker-devel list.. I'm trying to keep all
>> communication on the list. :-)
>> _______________________________________________
>> Beaker-devel mailing list
>> Beaker-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/beaker-devel
>
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/beaker-devel