Using Python/Tools/freeze to generate a compiled version of the harness
by Bill Peck
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?
13 years, 10 months
Re: [Beaker-devel] search implementation using synonym and Select
by Raymond Mancy
----- "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
>
> = True),
>
>
> There must be a better way to do what we want here.. Any thoughts?
After thinking about it more I think it could be a great idea to decouple that behaviour a bit. When I wrote it
I wasn't really thinking about how other parts of Beaker interact with the model.
Looking through the code I don't think it would be that hard to refactor these particular parts, as there are already some mechanisms
in place that will allow for the redeployment of some of this logic. The resulting code wouldn't be as succinct, but
it should remove these kinds of errors.
I'll create a ticket for it. Let me know if you would like me to try and change this ASAP, or if it's something we can live with for a bit
longer.
Raymond
13 years, 10 months
Re: [Beaker-devel] search implementation using synonym and Select
by Raymond Mancy
----- "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
13 years, 10 months
search implementation using synonym and Select
by Bill Peck
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?
13 years, 10 months
Re: [Beaker-devel] Ticket 55
by Raymond Mancy
----- "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
13 years, 10 months
Re: [Beaker-devel] Ticket 55
by Raymond Mancy
----- 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
>
13 years, 10 months
null, empty string, whitespace
by Kevin Baker
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
13 years, 10 months
Re: [Beaker-devel] Ticket 55
by Marian Csontos
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
>
13 years, 10 months
Re: [Beaker-devel] Ticket 51
by Raymond Mancy
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.
13 years, 10 months
Re: [Beaker-devel] Ticket 55
by Raymond Mancy
----- 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. :-)
13 years, 10 months