*** holycow has joined #gnuenterprise
*** holycow has quit IRC
<rynik> good morning
<mnemoc> hi rynik
<rynik> hi mnemoc, Have you done some imports?
<mnemoc> after 5 hours doing that silly import i decided to abort
<mnemoc> i moved the commit inside the loop, and it's lots faster and i see the results inmediately
<mnemoc> i also saw that my 'user' was too long and aborted on the first iteration
<mnemoc> s/aborted/failed/
<rynik> But what now, can you sit back and let it work for you? Although I don't think you will make it in time for your deadline two days ago. Unless you have a very swift macine. :)
<mnemoc> :)
<mnemoc> real    29m12.617s
<mnemoc> user    2m31.853s
<mnemoc> sys     0m34.806s
<mnemoc> much better
<mnemoc> 7189 records
<mnemoc> last time it had processed around 4000 in 5 hours
<mnemoc> i'll go to sleep, and do some tests of the full importer in the morning, now it 2:20am here :)
<mnemoc> and my girls wake up around 6:30
<mnemoc> i'm liking this thing.... i guess i'll do the plone (python again, puaj) module for it
<mnemoc> milk bottles ready, cu in some hours :)
<rynik> cu mnemoc
*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<reinhard> mnemoc: sorry, I wanted to help you more yesterday, but I had internet outrage :(
*** reinhard has quit IRC
*** reinhard has joined #gnuenterprise
*** docelic has joined #gnuenterprise
*** docelic has quit IRC
<reinhard> huh?
<dimas> reinhard: how to initialize appserver session if authentication = True ?
<dimas> when switched off
<dimas>   session = app.newSession ('dimas', 'secret')
<dimas>   session.setcontext ('PERSON')
<dimas> works fine
<reinhard> should work with 1st parameter username and 2nd parameter password
<reinhard> IIRC
<reinhard> you might run into troubles if you have filters
<reinhard> but regardlessly whether you have authentication or not
<dimas> it says app: User 'None' does not exist
<reinhard> svn or release?
<dimas> svn
<dimas> yesterday's
<dimas> what troubles with filters? how to get it work properly?
<dimas> or what would you recommend?
<reinhard> dimas: I think I fixed the login problem
<reinhard> will talk to johannes that he should fix filters with App.Session sessions
<dimas> reinhard: thanks
<dimas> updating..
*** johannesV has joined #gnuenterprise
<johannesV> palim palim
<reinhard> hello
<reinhard> johannesV:
<reinhard> erm
<reinhard> hello, johannesV :-)
<johannesV> i'm just about to test my new (external) 250gb usb hard-driver
<johannesV> erm harddrive
*** docelic has joined #gnuenterprise
<johannesV> reinhard, have you noticed that problems in file-based drivers regarding import of modules (in initplugin)
<johannesV> i.e. dbffile.py does not import that dbf module in initplugin
<reinhard> yes, fixed it
<reinhard> it does import that
<reinhard> but appearantly it imports it into the local namespace of the __initplugin__ procedure
<reinhard> which doesn't help much :)
<johannesV> well, but now we have an import statement in both functions _loadFile and _listFields
<reinhard> yes
<reinhard> I am not sure if there is a better way of doing it
<reinhard> like adding a "global dbf" to __initplugin__
<johannesV> anyway, i've downloaded xbase specs from web and i will do our own implementation of a dbf-driver
<johannesV> so that silly question 'which driver to use' get's obsolete
<johannesV> (and we could make it iterable:)
<reinhard> you would do your own dbf.py?
<reinhard> or directly integrate it into dbffile.py?
<johannesV> i'm not sure about that
<johannesV> what would you prefer ?
*** johannesV_ has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
<reinhard> I think it would make sense to have a gnue-independent dbf.py
<johannesV_> ok, and where to put that ?
<reinhard> include it into python 2.5 standard ;-)
<johannesV_> *lol*
<reinhard> gnue-common/src/utils/dbf.py
<reinhard> we have lots of other useful non-gnue-dependent stuff there already
<reinhard> like CaselessDict or uuid
*** johannesV has quit IRC
<reinhard> all stuff one could easily rip out of gnue and use in another project
<SachaS> to save the world in other projects ;)
<johannesV_> right, i think that's a good idea
<reinhard> johannesV_: I'm just not sure if the dbffile should be an iterator yielding lists  (like the existing dbf.py's are) or an iterator yielding dictionaries
<reinhard> you could even try to subclass list and dict for the dbf objects
<reinhard> although I do not yet see the advantage in that
<reinhard> as opposed to creating a new class and implementing all those functions
<reinhard> that are needed for dict/list emulation
<johannesV_> well, i think we should keep that dbf.py driver quite simple (as we can decide over it's design :)
<reinhard> yeah
<reinhard> I envision something like
<reinhard> for row in dbffile ('/path/to/file.dbf'):
<reinhard>   print row ['name']
<johannesV_> what's dbffile here ?
<johannesV_> our datasource.driver.file.dbffile ?
<johannesV_> btw. i'd prefer an iterator yielding dictionaries
<johannesV_> (where we have to decide about case then)
<reinhard> johannesV_: no, sorry
<reinhard> johannesV_: i meant the class
<reinhard> for row in dbf.dbffile
<reinhard> or dbf.dbf
<reinhard> or however we want to call that class
<johannesV_> ok, i'd prefer to call it 'dbf.dbf' to avoid confusion with our dbffile.py
<reinhard> ok
<reinhard> actually my reason to call it dbffile was to avoid confusion with the current dbf :)
<reinhard> so it certainly makes sense :)
<johannesV_> ok, great :)
<johannesV_> what about that idea mentioned the last days having a 'database' attribute in a connections.conf entry for file-based drivers pointing to a directory, having all files (of a given type/extension) beeing a table of that db ?
<reinhard> johannesV_: you can already do that with current svn
<johannesV_> ah, ok i wasn't sure about that ...
<johannesV_> but then .... that's great !
<reinhard> you can for example have
<johannesV_> how would i configure such a connections.conf entry ?
<reinhard> filename = %(home)s/mydata/%(table)s.dbf
<reinhard> or
<reinhard> filename = /home/johannes/dbftest/%(table)s/data.dbf
<reinhard> and %(table)s will be replaced by the respective table names
<reinhard> works for all file based drivers: csvfile, dbffile, and inifile
<johannesV_> ok, great ! thanks, will try that later ...
<johannesV_> i'm not sure if i'll add ndx-support to the first version
<johannesV_> cause we're having sort-support by file.Base anyway
<reinhard> johannesV_: I don't think it makes sense for a read only driver
<johannesV_> who said it will be read-only ?
<reinhard> lol
<johannesV_> j/k
<johannesV_> ok, i'm off for the next time (playing with the kids ...)
<johannesV_> bbl
*** docelic has quit IRC
<reinhard> bbl
*** reinhard has quit IRC
<mnemoc> how can i use COMMAND_OPTIONS if i use appserver.language.app directly on __main__ ?
<mnemoc> or, how can i use appserver.language.app as class base?
*** johannesV_ has quit IRC
*** reinhard has joined #gnuenterprise
<reinhard> mnemoc: you should be able to use gnue.common.language.App.App as a base class instead of GBaseApp or GClientApp
<reinhard> I think you just have to try with App.App instead of App
<reinhard> gnue.common.language.App is the python module
<reinhard> if you do "from gnue.common.language import App" then App will be the whole module
<reinhard> and App.App is the class
<reinhard> bbl
*** jcater has joined #gnuenterprise
*** sjc has joined #gnuenterprise
<rm-away> good night all
*** rm-away has quit IRC
*** Vee has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** kilo has quit IRC
*** wendall911 has quit IRC
*** yure has quit IRC
*** mnemoc has quit IRC
*** sjc has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** Vee has quit IRC
*** jcater has quit IRC
*** yure has joined #gnuenterprise
*** dimas has quit IRC
*** holycow has quit IRC
*** holycow has joined #gnuenterprise
*** holycow has quit IRC