Beaker-devel November 2009

beaker-devel@lists.fedorahosted.org

4 participants
16 discussions

Using Python/Tools/freeze to generate a compiled version of the harness
by Bill Peck 01 Dec '09

01 Dec '09

Hi Marian, I thought I'd mention that I stumbled across freeze for python. It allows you to compile python code into a native binary. python26 ../freeze/freeze.py -X PyDOC /usr/bin/beah-beaker-backend -m encodings -m encodings.hex_codec -m encodings.ascii I had to add the encodings since freeze didn't figure it out automatically. I also had to edit the config.c file that it generated. It improperly puts in a _warnings entry which is incorrect. After that I was able to compile the code with a simple make. [root@dell-pe1850-01 beah-beaker-backend]# eu-readelf -d beah-beaker-backend |more Dynamic segment contains 29 entries: Addr: 0x08390684 Offset: 0x348684 Link to section: [ 5] '.dynstr' Type Value NEEDED Shared library: [libpthread.so.0] NEEDED Shared library: [libdl.so.2] NEEDED Shared library: [libutil.so.1] NEEDED Shared library: [libm.so.6] NEEDED Shared library: [libc.so.6] INIT 0x08057f58 FINI 0x0813738c HASH 0x08048148 STRTAB 0x080504d0 SYMTAB 0x0804a880 STRSZ 24862 (bytes) SYMENT 16 (bytes) DEBUG As you can see its only linking against glibc and some other standard libraries. Everything else is static. [root@dell-pe1850-01 beah-beaker-backend]# ls -lh beah-beaker-backend -rwxr-xr-x 1 root root 3.5M Nov 30 15:28 beah-beaker-backend [root@dell-pe1850-01 beah-beaker-backend]# ./beah-beaker-backend /usr/lib/python2.6/site-packages/twisted/spread/pb.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 BackendFactory : Started to connect. BackendFactory : Connected. Address: <twisted.internet.address.IPv4Address object at 0xb6f4804c> BackendFactory : Resetting reconnection delay start <function callRemote at 0xb6f42d84>(*(<beah.backends.beakerlc.LoggingProxy instance at 0xb6f480ac>, 'get_recipe', 'dell-pe1850-01.rhts.eng.bos.redhat.com'), **{}) { } <function callRemote at 0xb6f42d84> returned <Deferred at 0xb6f4812cL> XML-RPC call get_recipe failed: [Failure instance: Traceback: <class 'xmlrpclib.Fault'>: <Fault 1: "beaker.server.bexceptions.BX:'No active recipe for dell-pe1850-01.rhts.eng.bos.redhat.com'"> /usr/lib/python2.6/site-packages/twisted/protocols/basic.py:239:dataReceived /usr/lib/python2.6/site-packages/twisted/web/http.py:467:rawDataReceived /usr/lib/python2.6/site-packages/twisted/web/http.py:430:handleResponseEnd /usr/lib/python2.6/site-packages/twisted/web/xmlrpc.py:279:handleResponse --- <exception caught here> --- /usr/lib/python2.6/site-packages/twisted/web/xmlrpc.py:307:parseResponse /usr/lib/python2.6/xmlrpclib.py:1184:loads /usr/lib/python2.6/xmlrpclib.py:838:close ] original call: get_recipe(*('dell-pe1850-01.rhts.eng.bos.redhat.com',), **{}) The traceback is expected since we don't have an active recipe for this host. I think it would make sense to build the harness this way so we don't interfere with whats on the host. :-) What do you think?

2 2

Re: [Beaker-devel] search implementation using synonym and Select
by Raymond Mancy 25 Nov '09

25 Nov '09

1 0

Re: [Beaker-devel] search implementation using synonym and Select
by Raymond Mancy 24 Nov '09

24 Nov '09

----- "Bill Peck" <bpeck(a)redhat.com> wrote: > From: "Bill Peck" <bpeck(a)redhat.com> > To: "List for the development of the Beaker project" <beaker-devel(a)lists.fedorahosted.org>, "Raymond Mancy" > <rmancy(a)redhat.com> > Sent: Tuesday, November 24, 2009 4:46:41 AM GMT +10:00 Brisbane > Subject: search implementation using synonym and Select > > Hi Raymond, > > The search is working and its much better than anything I did so far. > > :-) But I'm hitting a few issues with the way its implemented. > > For example in the System mapper we have this: > > > 'Arch':column_property(select([arch_table.c.arch]).correlate(arch_table).label('Arch'),deferred 'Arch' here is a sub-select column label. In the beaker code, this column_property is only accessed if the System/Arch is being searched on. If the System/Arch is being searched on than other tables will be joined in the query. At that point, System.Arch will work as intended. Actually System/Arch is kind of unique in that it's represents a one to many relationship, this means the code around it is a bit more complex then say, System/Owner. > > = True), > > even though we also have the following as well: > > 'arch':relation(Arch, > order_by=[arch_table.c.arch], > secondary=system_arch_map, > backref='systems'), > 'arch' here is the relationship between the Arch class and the System class. Internally, 'Arch' and 'arch' are not confused. > <error code snipped> > > There must be a better way to do what we want here.. Any thoughts? Possibly there is a better way of implementing this. I did it this way for a few reasons. Firstly, when we create our drop down in beaker of 'Table/Column', it makes it easier to determine what we can search on. We can only search on things that are represented as a column within SQLalchemy. This means we can do things like automatically include all columns as part of the search, or selectively exclude some. Not a huge deal, but maybe handy. In SQLAlchemy we actually turn them into a column. Some of the things that we search on are actual columns of the table in the db(i.e System/Serial, where serial is a column of the System table), but many things we search on are just a relationship (i.e System/Owner). So mapping the relationship as a column means throughout the rest of the code we don't have to figure out whether or not it's an actual column. The rest of the code can be much simpler and more consistent. It makes it very easy to figure out the column type (which we then use to determine what oeprations can be done), the code that builds the query is much simpler etc. These were some of my goals when thinking about how to do the search. I'm sure there are caveats to it as well. Thoughts ? Raymond

1 0

search implementation using synonym and Select
by Bill Peck 23 Nov '09

23 Nov '09

Hi Raymond, The search is working and its much better than anything I did so far. :-) But I'm hitting a few issues with the way its implemented. For example in the System mapper we have this: 'Arch':column_property(select([arch_table.c.arch]).correlate(arch_table).label('Arch'),deferred = True), even though we also have the following as well: 'arch':relation(Arch, order_by=[arch_table.c.arch], secondary=system_arch_map, backref='systems'), This extra column is causing the following error to happen at times. I'm not sure which code is triggering it yet ( I do know its in the csv import code, possibly when it fails to import a system for one reason or another it calls expire or expunge). OperationalError: (OperationalError) (1054, "Unknown column 'arch.arch' in 'field list'") u'SELECT (SELECT lab_controller.fqdn \nFROM lab_controller \nWHERE lab_controller.id = system.lab_controller_id) AS `LabController`, system.private AS system_private, system.serial AS system_serial, (SELECT system_type.type \nFROM system_type \nWHERE system_type.id = system.type_id) AS `Type`, (SELECT system_status.status \nFROM system_status \nWHERE system_status.id = system.status_id) AS `Status`, system.lender AS system_lender, (SELECT tg_user.user_name \nFROM tg_user \nWHERE system.user_id = tg_user.user_id) AS `User`, system.memory AS system_memory, system.shared AS system_shared, (SELECT arch.arch) AS `Arch`, system.vendor AS system_vendor, system.date_added AS system_date_added, system.date_modified AS system_date_modified, system.fqdn AS system_fqdn, (SELECT tg_user.user_name \nFROM tg_user \nWHERE tg_user.user_id = system.owner_id) AS `Owner`, system.model AS system_model, system.id AS system_id, system.date_lastcheckin AS system_date_lastcheckin, system.location AS system_location, system.owner_id AS system_owner_id, system.user_id AS system_user_id, system.type_id AS system_type_id, system.status_id AS system_status_id, system.deleted AS system_deleted, system.checksum AS system_checksum, system.lab_controller_id AS system_lab_controller_id, system.mac_address AS system_mac_address, system.loan_id AS system_loan_id \nFROM system \nWHERE system.id = %s' [97L] And sure enough I can trigger it if I do the following from tg-admin shell >>> print system.Arch Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/attributes.py", line 158, in __get__ return self.impl.get(instance_state(instance), instance_dict(instance)) File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/attributes.py", line 374, in get value = callable_() File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/strategies.py", line 297, in __call__ query._get(None, ident=ident, only_load_props=group, refresh_state=state) File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/query.py", line 1431, in _get return q.all()[0] File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/query.py", line 1198, in all return list(self) File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/query.py", line 1292, in __iter__ return self._execute_and_instances(context) File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/query.py", line 1295, in _execute_and_instances result = self.session.execute(querycontext.statement, params=self._params, mapper=self._mapper_zero_or_none()) File "/usr/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 755, in execute clause, params or {}) File "/usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py", line 824, in execute return Connection.executors[c](self, object, multiparams, params) File "/usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py", line 874, in _execute_clauseelement return self.__execute_context(context) File "/usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py", line 896, in __execute_context self._cursor_execute(context.cursor, context.statement, context.parameters[0], context=context) File "/usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py", line 950, in _cursor_execute self._handle_dbapi_exception(e, statement, parameters, cursor, context) File "/usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py", line 931, in _handle_dbapi_exception raise exc.DBAPIError.instance(statement, parameters, e, connection_invalidated=is_disconnect) OperationalError: (OperationalError) no such column: arch.arch u'SELECT (SELECT arch.arch) AS "Arch" \nFROM system \nWHERE system.id = ?' [1] There must be a better way to do what we want here.. Any thoughts?

1 0

Re: [Beaker-devel] Ticket 55
by Raymond Mancy 15 Nov '09

15 Nov '09

----- "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

1 0

Re: [Beaker-devel] Ticket 55
by Raymond Mancy 15 Nov '09

15 Nov '09

----- 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... > 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 >

1 0

null, empty string, whitespace
by Kevin Baker 11 Nov '09

11 Nov '09

moving to beaker devel > On Tue Nov 10 19:03:03 2009, kbaker(a)redhat.com wrote: > > > > Does it handle empty string, whitespace string and NULL? > > > > I often got caught by these various ways of representing nothing. > > > > > > Before it was just checking for a an empty string/int So for > > > the 'is', If the value was whitespace, it would just do a > > > regular SQL query with = '' Now it will do 'IS NULL', which > > > will actually work with our outer join where the right table > > > has null values :-) > > > > > > Also for the 'is not', now if the value is blank than it will > > > do 'IS NOT NULL' (which again, will now work with our outer > > > joins). Also with 'is not', if we do say ['is not'] ['foo'] > > > the SQL will be != 'foo' OR IS NULL. > > > > <warning>: wandering off into the weeds.</warning> > > > > What do I do if I want to search for the empty string ''? Or for > > whitespace ' '? > > > > not saying it's a major issue, just if you considered it. As > > applications age and values get added/deleted they can fall off > > the radar. Consider > > > > time-0 - field created as NULL > > time-1 - field set to 'Blah' > > time-2 - field cleared to '' > > > > After time-0 searching for field IS NULL will return the record > > but after time-2 it will not. Depends on the application on what > > NULL versus empty string versus whitespace ' ' means. I guess > > I'm trying to warn against mapping undefined, empty string and > > whitespace to NULL at the db level. It may be safer to say (field > > IS NULL OR field = '') or provide UI to differentiate what you're > > searching for > > > > field IS NULL > > field IS NOT NULL > > field IS empty string > > field IS not empty string > > You're right about the first part. It's a 2 line fix. Silly oversight > on my behalf. > > In regards to the UI aspect of it. Firstly, will there be real > world cases of needing to look for say a System that has an empty > CPU/Processor entry vs not having a CPU/Processor entry at all? > Also, representing the NULL in the value is hard. We have an > operation field, and then a value field (which is just a text > field). How do we differentiate between the user wanting NULL or > wanting empty string in the textfield? Empty string is easy, the > textfield remains blank. For NULL though, would they just type NULL > in the textfield, and what if someone actually wanted to search > for a field which contained the string 'NULL' ? It could be error > prone and confusing. > > If there isn't going to be a compelling use case for it, it may > not be worth the added complexity. Yeh, this conversation is getting a little out there so I'll attempt to wrap it up. :) If the application is the only thing writing to the database then it can ensure that my example would never happen. So it would become time-0 - field created as NULL # created time-1 - field set to 'Blah' # modified time-2 - field set to NULL # cleared Then you can keep the UI & coding simple by assuming that NULL is not represented by empty strings or white space. -- Kevin Baker Manager Engineering Operations, Westford +1 978 392 2442

1 0

Re: [Beaker-devel] Ticket 55
by Marian Csontos 11 Nov '09

11 Nov '09

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... > > 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. > > 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 >

1 0

Re: [Beaker-devel] Ticket 51
by Raymond Mancy 10 Nov '09

10 Nov '09

Hi Bill, My plans with it thus far are; *Seperate the columns from the searchbar, have a 'toggle columns' button, similar to what we have with the searchbar. *Also want to seperate the checkbox column into multiple columns. Otherwise we could just end up with one long column that would scroll forever! *Have our regular columns preselected (although these could be unchecked by the user) Adding their searched columns as result columns should be easy enough as well. Yeah, at the moment it's very buggy. Also sorting is an issue, if you try and sort the results by the columns, it will crash and burn! Cheers ----- 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:41:18 AM GMT +10:00 Brisbane Subject: Ticket 51 Hi Raymond, This is starting to look good. I think I would separate the columns that are displayed from the search bar though. And whatever columns you search on should be added to the custom columns automatically. Also, have the current columns checked off (the ones we show by default) Also, right now the code doesn't work if you search without selecting some custom columns. You probably already know that.. but just in case. :-) Thoughts? This and the new search are really making this powerful! Thanks for your hard work.

1 0

Re: [Beaker-devel] Ticket 55
by Raymond Mancy 10 Nov '09

10 Nov '09

----- 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. :-)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel November 2009