*** holycow has quit IRC
*** johannesV has joined #gnuenterprise
<elwis> What's needed to get the ugly swedish letters working in gnu-eforms?
<elwis> I have them in my postgres table, but they won't show up proper in the forms?
*** lxf has joined #gnuenterprise
<dimas> hi elwis
<dimas> what encoding your forms are in?
<dimas> can you see that letters when in labels on the form?
<dimas> elwis:  gnue can show almost any letters for sure :)
<elwis> dimas: Hi there, sorry for having to answer a collleague
<elwis> when I do a select * from postgres in my console they show up alright
<elwis> in my gnue-form they look like something from outer space :(
<elwis> <?xml version="1.0" encoding="iso8859-1"?>
<elwis> I'll try labels
<dimas> is that proper encoding for those letters?
<elwis> Should be.. look yeak on the labels
<elwis> maybe utf8?
<elwis> utf-8 made them look great in gnue, now they're wrong in postgres :)
<dimas> there is encoding param for connections.conf
<elwis> ...yes.. I put that one on iso8859-1 .. if i change it to utf-8 it will be grwt all over??
<elwis> grwt = great .. (need more coffee for sure)
<dimas> [taxcom-backend]
<dimas> provider = psycopg
<dimas> host = localhost
<dimas> dbname = taxcom
<dimas> encoding = utf-8
<elwis> Thanx!
*** kilo has joined #gnuenterprise
<elwis> what about that terrible "brain|help|use" - less guide I wrote, should I put it on the web?
<dimas> where is it now?
<elwis> on my hddd :)
<elwis> I think someone should check it out, I might be lying about things..
<elwis> it's kind of an interesting story actually.. it starts out with a murder..
<kilo> good morning
<kilo> elwis: could you provide an url for it?
<kilo> if not, send it to me and i will publish it before adding it to official site
<elwis> kilo: hold on, I'll see if I can get it on my old javaserver ;)
<kilo> ok
*** reinhard has joined #gnuenterprise
<reinhard> good morning
<dimas> hello reinhard
<kilo> hi reinhard
<johannesV> hi reinhard
<elwis> kilo:www.myjavaserver.com/~elwis/GNUe_for_the_helpless.pdf
<elwis> Now, if it stink, tell me so and I'll might be able to fix it ;)
<dimas> You'll notice that I'll be in the back trying to get some answers also..
<dimas> lol
<dimas> that is what #gnuenterprise is for :)
<dimas> and when it is you are not helpless..
<reinhard> <elwis> in my gnue-form they look like something from outer space :(
<reinhard> we have full klingon support in gnue ;-)
<elwis> so, THAT'S what it is.... ;)
<reinhard> elwis: did you get your encoding problems fixed?
<elwis> reinhard: I think so, utf-8 for the forms and utf-8 in connections.conf, but I haven't tried yet.. ;)
<elwis> *ouch* gave me such a huge error again, better dig into it
<elwis> suppose I couldn't change enocing in connections.conf all of a sudden..
<reinhard> elwis: that shouldn't be any problem
<reinhard> what version of gnue-common are you using, and what ui?
<elwis>  gnue-forms-0.5.11.99+svn.20050309
<elwis> ;DefaultUI = wx
<elwis> LANG=sv_SE.UTF-8
<elwis> if it matters
*** sjc has joined #gnuenterprise
<reinhard> elwis: hrmmm.... I am not sure if wx is capable of utf-8 at all
<reinhard> you should have more luck with gtk2 ui
<reinhard> if your version of gnue-common is recent enough, the encoding in connections.conf should not really matter
<reinhard> as it would only be the communication between db and gnue
<reinhard> but utf-8 should be a safe choice there anyway
<elwis> ok, I'll go for gtk2 and utf-8 all the way to try it out
<elwis> didn't work
<reinhard> you get error message or only strange characters?
<elwis> huuuuge error, I'm changing connections.conf back to iso to check it..
<reinhard> you can paste the last few lines of the error message here
<reinhard> the information that the error message is huge doesn't really help much in debugging ;-)
<elwis> there's a post containing swedish charcters,
<elwis>  if i change to utf-8 in connections.conf I get a ton of errors when trying to retrieve it with a query
<elwis> true, I wonder how I'll do it though.. can i redirect to logfile, cause this one pop's up a messagebox that 's too big to read
<dimas> what encoding your db created with?
<elwis> dunno ... I'm a postgres rookie, but it looked alright in the console
<dimas>  in psql list your db's with \l
<reinhard> elwis: it pops up a message box where the full error message is visible?
<reinhard> elwis: and you don't have a "Detail >>" button?
<dimas> \? for help
<elwis> in _loadNextRecord
<elwis>     f = unicode(f,self._dataObject._connection._encoding)
<elwis>  UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-2: invalid
<elwis> data
<elwis> test=# \encoding
<elwis> SQL_ASCII
<elwis> So, no utf-8 in my postgres I suppose..
<reinhard> ouch
<dimas> [ds@exodus ds]$ echo "\l" |LANG=C psql icsinfo
<dimas>         List of databases
<dimas>    Name    |  Owner   | Encoding
<dimas> -----------+----------+-----------
<dimas>  icsinfo   | ds       | KOI8
<dimas>  tandem    | gnue     | UNICODE
<dimas>  taxcom    | gnue     | UNICODE
<dimas>  template0 | postgres | SQL_ASCII
<dimas>  template1 | postgres | SQL_ASCII
<dimas> (5 rows)
<dimas> 
<elwis> so, one could choose unicode for the database? i better google that one (unicode is ok on win also right?)
<reinhard> but then i wonder how you made it work in console
<elwis> you mean from psql?
<reinhard> yes
<elwis> works nicely, I use "insert into" statement and can get them all?
<reinhard> hmm
<reinhard> maybe you really have to create the db with unicode
<reinhard> but actually if you used gnue-setupdb it should have done that
<reinhard> did you check the db list like dimas said above?
<elwis> nope, I tried the command but there's no "icsinfo"
<elwis>  gnue      | postgres | SQL_ASCII
<elwis>  template0 | postgres | SQL_ASCII
<elwis>  template1 | postgres | SQL_ASCII
<elwis>  test      | sel      | SQL_ASCII
<elwis> looks like I better make a note about getting the unicode support when creating my "real" db
<reinhard> hrm
<reinhard> how did you create the db?
<reinhard> did you use gnue-setupdb or did you create it "manually"?
<elwis> the "test" I created using "created" statement
<reinhard> ok
<reinhard> there's a gnue-setupdb for creating and initializing the db
<reinhard> that would create it correctly with unicode support
<elwis> I donät remember if I ever got that to work, that might be the cause of it
<reinhard> err wait
<dimas> elwis: createdb accepts -E param for encoding
<reinhard> you don't use appserver, right?
<reinhard> elwis: forget what i said about gnue-setupdb
<reinhard> please ignore me from now on
<reinhard> :)
<elwis> dimas: yes, I just found that in the postgres manual
<dimas> reinhard: you are an appserver addict :)
<kilo> elwis: I have read through your doc, I think it is quite enjoyable and aside from some typos there is only valid info in it. Great!
<elwis> kilo: you didn't fall asleep, did you :)
<kilo> well, as i said, i liked your style
<elwis> I was a little bit afraid that it were a little bit "too loose" and would not be taken seriously at all
<elwis> for typos: http://www.myjavaserver.com/~elwis/GNUe_for_the_helpless.sxw
*** elwis has left #gnuenterprise
*** lxf has quit IRC
*** dcmwai has quit IRC
*** elwis has joined #gnuenterprise
*** havoc has joined #gnuenterprise
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** reinhard has quit IRC
*** jamest has joined #gnuenterprise
<jamest> johannesV_: you here?
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** michael301080 has joined #gnuenterprise
<michael301080> al lot better without the Chanserv message, thanks
<jamest> :)
<michael301080> probably OT: Can anyone give me advice about plone?
<michael301080> thanks, Jamest
<jamest> the one person I know that used it extensively is jcater
*** reinhard has joined #gnuenterprise
<jamest> reinhard: i read the appserver userguide last night
<michael301080> I want to know how Gnue can interact with it.
* jamest is debating changing the way things work here
<jamest> michael301080:interact with it?
<michael301080> as in: have a webapplication that shows data out of GNUe
<michael301080> or: how can a plone site (or webapplication) have a GNUe back-end?
<jamest> reinhard: i imagine i could access appserver via datasources in a stand alone application
<jamest> reinhard: but i'm wondering if its possible to treat appserver classes like regular python classes
<jamest> so that if a customer class has a defined function of foo
<jamest> then i could in my app get a resultset of customers and do
<jamest> for customer in customerResultSet:
<jamest>   customer.foo()
<jamest> michael301080: my zope site hits the postgresql tables directly
<reinhard> jamest: that's exactly what you can do
<jamest> michael301080: but I think it wouldn't be too hard to expose gnue-common to zope via a small (few line) product in zope
<reinhard> jamest and michael301080: an answer to both of your questions
<jamest> michael301080: i've done this with some other python modules
<reinhard> the fellowship of the fsfe runs a plone site with a gnue backend
<michael301080> I read on the Gnue site that Gnue Forms can make HTML forms, ..
<reinhard> the fun thing there is that plone and gnue run on completely different systems
<jamest> reinhard: nice
<reinhard> so if you create a user in plone
<reinhard> plone creates the user with zero permissions
<reinhard> sends an encrypted mail with user data (also delicate data like birthday, sex, snail address etc that isn't stored on plone side)
<reinhard> to the server running gnue
<reinhard> a procmailrc then calls a script doing things like
<reinhard>   f = session.new ('fellow')
<reinhard>   for (key, value) in variables.items ():
<reinhard>       f [key] = value
<jamest> reinhard: is this an appserver gnue backend?
<reinhard> then the user can pay the fellowship fee via paypal
<reinhard> yes of course appserver
<reinhard> paypal sends a message to a cgi script on a webpage (can be configured in paypal) upon arrival of payment
<reinhard> that webpage sends another encrypted mail to gnue again processed with procmail
<reinhard> doing things like
<reinhard>   f = find_fellow (session, 'fellowship_paypalid', paypalid)
<reinhard>     p = session.new ('fellowship_payment')
<reinhard>     p.date =  mx.DateTime.strptime (variables ['payment_date'] [0],
<reinhard>                                     '%T %b %d, %Y PST')
<reinhard>     p.amount = int (float (variables ['mc_gross'] [0]))
<reinhard>     p.fellow = f
<reinhard> (variables is a dictionary that's passed by paypal containing amount, date etc)
<michael301080> interesting
<reinhard> then appserver does in a trigger set a property "ploneactive" to true upon a payment is inserted
<reinhard> in another trigger if ploneactive is set to true another encrypted email is sent from gnue back to plone
<reinhard> where a procmail runs and changes the role of the user from "Inactive" to "Member"
<reinhard> I can tell you that was big fun implementing :)
<jamest> lol
<michael301080> how long does this proces usually take?
<reinhard> 10 or 20 seconds
<reinhard> jamest: using the python language interface, you can access gnue objects just like python objects
<reinhard> so if you have an object "customer"
<reinhard> you can do
<reinhard> customer.name = "fred"
<jamest> that's what I'm after
<jamest> sorta
<reinhard> customer.openPayment += value
<reinhard> customer.delete ()
<michael301080> cool
<reinhard> customer.dosomethingweird ()
<michael301080> even cooler
<jamest> i'm debating the merrits of putting all functions into appserver objects
<reinhard> if you have an invoice object you can even do
<reinhard> c = invoice.customer
<jamest> vs wrapping appserver objects in a custom ajrs object
<reinhard> print c.name
<reinhard> but you can even do
<jamest> with appserver dealing w/ storage and basic processing on commits
<reinhard> print invoice.customer.name
<jamest> it looks like you can still define primary keys other than gnue_id in tables
<reinhard> nope you can't
<jamest> you can't?
<reinhard> no
<jamest> i musta mis-read something
<reinhard> you can define indexes
<reinhard> other than gnue_id
<kilo> pk is always gnue_id
<reinhard> but they will never be a primary key
<jamest> bad terminology
<jamest> for appserver the gnue_id is the PK
<kilo> aye
<jamest> but if I needed to port an existing app other that uses the customer_id field
<jamest> then i can still use the old table structure and thus the customer_id
<jamest> it doesn't mangle the table field layout
<reinhard> not sure if i understand
<jamest> here we have a claim table
<jamest> claim_no is PK
<jamest> then we have a notes table
<reinhard> but if you move from 2-tier to appserver you probably have to somehow migrate the data
<jamest> claim_no is FK ref to claim table
<jamest> that relationship can still be maintained
<reinhard> in that case I would
<michael301080> thanks allready guys, bbl
<reinhard> in claim table add the gnue_id field and fill it with the value from claim_no
<reinhard> then in notes table claim_no would not refer to claim_no of claim table, but to gnue_id
<reinhard> this way appserver would be aware of that link and could do smart things which it can't do otherwise
<reinhard> but  you have to be aware also that the _ has a special meaning for appserver
<reinhard> as it separates the module (namespace) identifier with the actual name
<jamest> gack
<jamest> i have a *lot* of field_names
<jamest> and what of authentication?
<reinhard> authentication is TBD
<reinhard> planned for next release
<reinhard> erm
<reinhard> next milestone I mean
<reinhard> for 0.5.0
<jamest> :)
<jamest> what I'm dealing w/ here
<jamest>   legacy app written in java
<jamest>   lots of new gnue-common based "apps"
<jamest> that create invoices, reports, picktickets, etc, etc
<jamest> i'm moving the java app under netbeans w/coyote (for jython support) and have it working with a thin jython wrapper
<jamest> now I'm wanting to begin migration away from the java app as the UI and logic are tightly coupled
<jamest> to something more like forms
<jamest> with ui and logic seperate
<jamest> with all the logic in gnue (and I'm thinking appserver)
<jamest> my thinking was that w/ appserver i could eliminate my batch jobs
<reinhard> I'd seriously recommend that you just play a bit with appserver to get a feeling of what's possible and what isn't
<jamest> and with jython i could keep the swing based front end
<jamest> until i'm ready to replace
<jamest> reinhard: most likely i'll just have to pick a project and roll with it
<jamest> my workload is nuts here
<jamest> and I'm wanting to get a handle on it
<jamest> ditching the high maintenance java crap with even a better designed piece of java crap would help
<kilo> jamest: pick the smallest app and try to do it in appserver
<reinhard> yes, exactly what I wanted to propose, too
<jamest> as that thing is a nightmare
<reinhard> jamest: I offer support contracts for appserver
<reinhard> j/k
<jamest> :)
<jamest> reinhard: what concerns would you have moving to appserver today?
<jamest> as you know it best :)
<reinhard> depends on the application
<reinhard> number of simultaneous users etc
<reinhard> main concerns would be
<reinhard> 1. as appserver is not yet multithreaded, it doesn't scale well for a large number of simultaneous users (lekma had to learn this under sweat and tears)
<reinhard> i.e. if one user does a query running 5 minutes, all other users are blocked
<reinhard> 2. appserver has no security yet
<reinhard> 2 is to be adressed in 0.5 and 1 in 0.6 releases
<reinhard> but as usual no promises about ETA
<reinhard> also we of course have not really *much* experience with using it in production
<reinhard> I do for a year now or so in my hotline project
<reinhard> but thats 1 simultaneous user and a non-mission-critical system
<jamest> has it really been a year?
<jamest> sigh, life is racing by
<reinhard> I think, yes
<reinhard> maybe 3. I don't even know whether using appserver is good or bad for performace compared to 2-tier
<jamest> 1 would be a showstopper as i do have ~25 people using the system at this time and that number should grow once we hit the new building
<jamest> 2 would be a minor problem
<reinhard> if you have any chance to separate out a smaller, relatively independent subsystem with a smaller simultaneous user base, I'd go for a first test with that
<reinhard> (if I were you)
<jamest> 3 is a non issue almost.  I'm  to the point that i have several apps that do almost the same thing w/ our data.  I've got an ajrs.common library but it isn't enough
<jamest> so I'm seriously thinking of refactoring (via netbeans for java, eric for python) this app.  using junit and pyunit to create tests
<jamest> as currently i tweak ajrs.common to account for one apps needs and it breaks another app
<kilo> bbl
<reinhard> well there's a lot of pros for appserver of course
<reinhard> it has a well documented, commented and stable code base
<reinhard> it is based on common
<reinhard> (so much of what it does is already known to you)
<reinhard> and most important of all
*** kilo has quit IRC
<reinhard> if you have any need
<reinhard> we accept patches ;-)
<jamest> anything I do now is based on common :)
<michael301080> reinhard: suppose I want to make an extranet, ...
<michael301080> and alow customers certain actions on the extranet based on the data that would be in appserver.
<michael301080> (if a company is running some of it's business processes on appserver)
<michael301080> wouldn't it be easiest to do have appserver storing it's data in a database and ...
<reinhard> well, appserver *always* stores data in a db :)
<michael301080> have the extranet website interact on a similar database, ..
<reinhard> you can read that db out as you like
<michael301080> and then setup replication between the two
<reinhard> but with direct writing you have to be careful
<michael301080> I'm talking 2 DB's here
<reinhard> as with appserver, gnue can take care of some things
<reinhard> well, replication would mean db1 writes to db2 on snyc
<michael301080> and vice versa ?
<reinhard> and if the website db writes back to the main db, that means you have write access that isn't checked
<reinhard> so you could create inconsistent state
<michael301080> I thought that was possible too, although I'm not a replication expert
<reinhard> I'm not either
<reinhard> gotta run
<reinhard> bbl
*** reinhard has quit IRC
<michael301080> OK
*** titopbs has joined #gnuenterprise
*** SachaS has joined #gnuenterprise
*** michael301080 has left #gnuenterprise
*** SachaS has quit IRC
*** SachaS has joined #gnuenterprise
*** elwis has left #gnuenterprise
*** WageMage has joined #gnuenterprise
<jamest> hi
<WageMage> Hi folks, any ideas about "system requirements" for gnue on win32 ? (Or is it a "if it can run windows and your database server you'll be fine" kind of deal?)
<jamest> i've not used it on windows in a while, but i'd say the latter
<jamest> i should rephrase that, i've not used it on slower hardware in a while
<jamest> but a few years ago it ran ok w/ win98 and iirc a 450mhz system
<WageMage> Ah - should be ok on my 800Mhz 512MB system, then... runs w2k and mysql just fine.
<WageMage> Thanks
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
<jamest> http://excess.org/urwid/
<jamest> not sure of that'd be of interest or not for the curses interface but figured i'd post here so it'd be in the logs :)
*** havoc_ has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
*** cilkay has left #gnuenterprise
*** tiredbones has quit IRC
*** reinhard has joined #gnuenterprise
<jamest> hey reinhard
<jamest> any recent changes in gDebug?
<chillywilly> hi jamest
* jamest doesn't recall seeing anything in the cvs commit logs
<jamest> hi chillywilly
<jamest> but my in house apps don't work w/ gnue svn
<chillywilly> hmmm, think I need some food
<chillywilly> badly
<jamest> and trying to set a debug level is giving me index errors
<jamest> ok it was commit 7130
*** WageMage has quit IRC
<reinhard> jamest: you found it?
<jamest> no, it doesn't make sense
<jamest> it's the same code only cleaned up
<reinhard> there *were* changes in GDebug
<jamest> but the extract_stack() in gDebug is returning an empty []
<jamest> instead of file info
<jamest> ah
<jamest> hmmmmm
<jamest> gDebug doesn't work w/ psyco
<reinhard> what is psyco?
<jamest> http://psyco.sourceforge.net/
<jamest> like my main app here
<jamest> if __name__ == "__main__":
<jamest>   TaxReport.run()
<jamest> rewrite to
<jamest> if __name__ == "__main__":
<jamest>   try:
<jamest>     import psyco
<jamest>     psyco.full()
<jamest>   export ImportError:
<jamest>     pass
<jamest>  TaxReport.run()
<jamest> more than dbls the speed of that report
<reinhard> ah
<reinhard> well
<jamest> but frags gdebug :)
<reinhard> somewhere they have to get that saved time from ;-)
*** johannesV_ has quit IRC
<reinhard> probably breaks all traceback information then
<jamest> tracebacks still work with psyco
<reinhard> which means it would also break gettext
<jamest> but something odd is happening there
<reinhard> I mean call stack analysis
<jamest> ok there has been a change to the datasources
* jamest is trying to find simple sample
<jamest> ok, in the old datasources you could do
<jamest>   prodDatasource = DataSourceWrapper(connections,
<jamest>                                      attributes={'connection': PROD_CONNECTION,
<jamest>                                                  'name': 'dtsProd',
<jamest>                                                  'table': 'invoice', })
<jamest>   batchResultSet = prodDatasource.createResultSet(conditions={'invoice_no':invoiceNumber},
<jamest>                                                   readOnly=1)
<reinhard> that should still work actually
<reinhard> (from what I can tell)
<reinhard> what doesn't work here?
<jamest> sorry, trying to find sample
<jamest> and the sql generated would read
<jamest> (i'm on 2 computers so cut n paste isn't an opton :)
<jamest> select * from invoice where (((invoice_no = '12345')))
<jamest> the new datasources generate
<jamest> select oid from invoice where (((invoice_no = '12345')))
<reinhard> ah oh
<reinhard> that's an accidental breakage
<jamest> so later references to
<jamest>   for record in batchResultSet:
<jamest>     return record['claim_no']
<jamest> puke :)
<reinhard> the "*" is added if no field is referenced
<reinhard> but with our rowid support the rowid is always referenced
<jamest> :)
<reinhard> so the "*" never gets into effect any more
<jamest> is that in base?
<jamest> or dbsig
<reinhard> base
<jamest> and i can fix
<jamest> thanks, figured you'd know faster than glimpse would :)
<reinhard> question is what is best fix
<reinhard> well, I think the "*" code might be in dbsig2
<jamest> i'll dig
<jamest> at the time of sql contruction i'd assume we'd already know the key fields in use
<reinhard> I think in DBSIG2/DataObject.py _buildQuery
<reinhard> where you have if self._fieldReferences
<jamest> the elif
<reinhard> we would maybe like to have an additional flag if any fields were explicitly or implicitly referenced
<reinhard> i.e. referenceField() would set a flag to true
<reinhard> but those automatic field references for master/detail, primarykey and rowid support would not set it to true
<reinhard> (fwiw I suspect the problem would always have been there if you had datasources with master/detail without fields)
<reinhard> or sorting for that matter
<reinhard> (Sort fields are also added to _fieldReferences)
<reinhard> (which I'm not sure I understand why)
<jamest> i never do master/detail datasource in my custom apps
<jamest> so i'd not have tripped it before
<jamest> anything complex I define the sql directly
<jamest> reinhard: at one time we talked about on the fly sort
<jamest> wouldn't that require the sort fields to be referenced in that situation?
<reinhard> on the fly sort == resorting an existing resultSet?
<reinhard> yes, that would require that
<jamest> yes
<reinhard> or you mean sorting newly inserted records into the right position automatically?
<jamest> the former
<jamest> so in a form you could select your sort order via a dialog
<reinhard> well, resorting would then need the *new* sort fields referenced
<reinhard> not those that the query is sorted by anyway
<reinhard> well, to sort back those would be needed too :)
<jamest> it would only have included the fields referenced
<jamest> so fields not used in sort or implicitly would be out of the game :)
<jamest> fwiw: i have no idea if that's why it's referenced
<jamest> but it's the one thing I can think of that might have made it included
<reinhard> ok
<reinhard> now what about the fix?
<jamest> i'm still reading datasource code and trying to remember how it all fits together
<jamest> it's only been what now?  5 years?
<reinhard> should I try one?
<reinhard> I could commit and you could test :)
<jamest> :)
<jamest> sure, if you know where to put it
<jamest> as I'm still re-groking the dataobject/datasource connection
<jamest> lol
<jamest>         #disable the count query and see if anyone screams.
<jamest>         #recordCount = self._getQueryCount(conditions,sql)
<jamest>         #  ARGH!!!! Oh, the agony... the agony....
<jamest> as a bit of history
<jamest> some dbsig drivers used to not return a proper rowcount
<jamest> it'd always be 0
<reinhard> does SELECT oid, * FROM table work?
<jamest> on postgresql it will
<jamest> so YES
<reinhard> and does SELECT oid, normalfield, * FROM table work?
<jamest> it's perfect :)
<jamest> um, that...lemme check
<jamest> i think so
<jamest> yip
<jamest> with one issue
<jamest> you'll get oid, normalfield, all other fields including a 2nd copy of normalfield
<reinhard> jamest: committed it
<reinhard> actually I don't even think that this will break anything
<reinhard> (the 2nd copy of normalfield)
<reinhard> as the code "_fields ['normalfied'] = ..." will just be executed twice
<jamest> right
<jamest> just thought i'd point that out
<reinhard> you should be able to try it now
<jamest> as it will slow things down some
<reinhard> although it's completely untested
<reinhard> well, for that matter a select * is bad programming style anyway IMHO
<reinhard> as in a month you might add a CHAR (5000) to that table for some reason and forget about the select * you did in this program
<reinhard> the normalfield will only occur if you have your DataSourceWrapper with sorting or with primarykey
<reinhard> both cases that wouldn't have worked at all until now (AFAICT)
<reinhard> so it's at least an improvement :)
<jamest> looks like that's working now
<jamest> and you have a point on the field references
<jamest> it was added for lazyness
<jamest> so maybe it should not be in there and i'll just adjust my apps to pass in the field names
<reinhard> it seems to be not portable either
<reinhard> as mysql and others seem to not give the field names
<reinhard> also this reading the field names from the cursor object always was a source for problems
<reinhard> like when fieldnames are returned by cursor object slightly different than they were passed in the select
<jamest> then lets just ditch it and I'll adjust
<jamest> i think jcater used it as well
<reinhard> I think we might want to generate a depreciation warning for some time
<jamest> but he's not here to object :)
<reinhard> actually
<reinhard> I even think the whole "select where 1 = 2" was only necessary to get the field names for the select * case
<reinhard> but I'm not fully sure I understood the rationale behind that bogus select at all
<jamest> that doesn't seem right though
<jamest> as the 1=2 thing was required long before the * was grafted in
<reinhard> do you remember why?
<jamest> i'm trying
<jamest> it had something to do with getting a good empty resultset  iirc
<jamest> but like the rowcount issue it may be long gone
<reinhard> the rowcount issue is not gone :)
<reinhard> still there for adodbapi and interbase
<jamest> lol
<reinhard> working on a _brokenRowcount parameter for DBSIG2 standard dataobject
<reinhard> so adodbapi and interbase don't have to duplicate a few screenfulls of code from DBSIG2 with 2 or 3 lines changed
<jamest> along the lines of the broken fetchmany
<reinhard> yes exactly
*** titopbs has quit IRC
<reinhard> but still got some customer work to finish today :(
<reinhard> and so many things I want to clean up in datasources left...
<SachaS> reinhard: will someone be able to use parts for python persistency?
<SachaS> seems like you are doing parts ofit
<SachaS> of it.
<reinhard> don't understand that question
<reinhard> you mean persistent objects?
<reinhard> in a way appserver objects are exactly that
<SachaS> yep that is what i meant
<reinhard> but with a predefined set of properties and methods
<SachaS> interesting to follow what you are doing
<SachaS> from far away
<SachaS> too far.
*** kilo has joined #gnuenterprise
<SachaS> this is cool:
<SachaS> http://ftp.acc.umu.se/mirror/temp/seth/blog/xshots.html
*** titopbs has joined #gnuenterprise
<reinhard> time to head to bed
<reinhard> night all
*** reinhard has quit IRC
*** jamest has left #gnuenterprise
*** SachaS has quit IRC
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** sjc has quit IRC
*** titopbs has quit IRC
*** kilo has quit IRC
*** jamest has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
<chillywilly> hi cilkay
<cilkay> hi chillywilly
<jamest> chillywilly: use still python'n ?
<chillywilly> yea, to various degrees
<jamest> you use unittest?
<chillywilly> I have been meaning to
<chillywilly> ;P
<jamest> lol
<jamest> never mind then :)
<chillywilly> actually I use it on the client side with stinking PHP
<chillywilly> fine then be that way ;)
<chillywilly> real men write the test cases first, then the code ;)
*** dcmwai has joined #gnuenterprise
<jamest> :)
*** cilkay has left #gnuenterprise
*** jamest has quit IRC
*** holycow has joined #gnuenterprise
*** Vee2d2 has quit IRC
*** Vee2d2 has joined #gnuenterprise