*** dimas has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> reinhard, if you read the logs, please check if queries using joins still work for you with your appserver ...
<johannesV> there's a point where an 'unqualified' gnue_id is mixed into the query-string: like select t0.address_name,gnue_id from ...
<johannesV> you could use appserver/samples/testing/dirty.py for this
*** sjc has joined #gnuenterprise
<johannesV> hmm, reinhard, maybe this ambiguous field is introduced by the 'default'-sorting (gnue_id)
<johannesV> no, that's just nonsense
<johannesV> oh, now i think i've found it ...
<johannesV> it's the right
<johannesV> erm, it's in line 279 of GDataSource.py
<johannesV> where you add the _primaryIdField to the fieldReferences
<johannesV> you do not take care of table-aliases there ... well, acutally that's hard to track there ...
<johannesV> do we really need to add the primaryKeyField to the field-references ?
*** dimas has quit IRC
*** dimas has joined #gnuenterprise
*** thesandroid has joined #gnuenterprise
*** thesandroid has quit IRC
*** thesandroid has joined #gnuenterprise
*** lekma has joined #gnuenterprise
*** thesandroid has left #gnuenterprise
<dimas> johannesV: you here?
<dimas> johannesV: with new fresh appserver,common code
<dimas> DB000:    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/appserver/repository.py", line 644, in finalize
<dimas> DB000:     r = verifyType (self.gnue_type, self.gnue_length, self.gnue_scale, classes)
<dimas> DB000:    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/appserver/repository.py", line 937, in verifyType
<dimas> DB000:     verifyBasetype (typename, length, scale)
<dimas> DB000:    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/appserver/repository.py", line 906, in verifyBasetype
<dimas> DB000:     raise TypeFormatError, u_("number without 'length'")
<dimas> DB000:  TypeFormatError: number without 'length'
<dimas> [
<dimas> johannesV: appserver works if i comment out number/lenght checking
<dimas>   #if typename == 'number':
<dimas>   #    if not length:
<dimas>   #      raise TypeFormatError, u_("number without 'length'")
<dimas> 
<dimas> about lines 890 in repository.py
*** SachaS has joined #gnuenterprise
<dimas> when committing any changes from form:
<dimas>    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/Base/Connection.py", line 135, in insert
<dimas>     self._insert (table, newfields, recno)
<dimas>    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/appserver/appserver/Connection.py", line 163, in _insert
<dimas>     id = f.pop ('gnue_id')
<dimas>  KeyError: 'gnue_id'
<johannesV> dimas, please do not comment out that lines
<johannesV> have a look at your gcd's instead ...
<johannesV> since this was a 'bug-fix'
<johannesV> we do not have/support numbers without length
<johannesV> the second one is a bit more interesting
<johannesV> i think it's because i've commented out a line in GDataSource
<johannesV> which acutally broke the joins in appserver
<johannesV> (it was reinhard's work though)
<johannesV> dimas, i've reverted the second one .... so inserting new data will work again, but joins won't ...
<johannesV> i think we've to wait for reinhard doing a fix to this, as it was him who started that massive rebuild in common's datasources
<dimas> johannesV: how would look those improper number in gcd?
<johannesV> grep all your gcds for type="number"
<johannesV> if you don't have any, there's bug in there ...
<johannesV> maybe i can change it to give a better exception ...
<dimas> i have one place with number(5.0) where other .gcd's using (n,m) notation
<johannesV> or even better, gnue-readgcd should also typecheck
<johannesV> ah
<dimas> but you were saying that we support both?
<johannesV> yes, in gnue-schema !
<johannesV> :)
<johannesV> commited just an addition to GCParser.py
<johannesV> so gnue-readgcd now supports both too
<dimas> thanks :)
<johannesV> np
<johannesV> anyway, the bigger problem will be that _primaryIdField introduced by reinhard last week
<johannesV> dimas, so you should now be able to start up appserver, do you ?
<johannesV> and it should come up a bit faster than yesterday ...
<johannesV> bbl
<dimas> it is superfast :)
<johannesV> yeah ... my last measuring was about 62 times faster than before :9
<dimas> wow
*** dcmwai_ has joined #gnuenterprise
*** dcmwai has quit IRC
<lekma> johannesV: can you help a bit plz
<lekma> it seems abort() is not globally declare
<lekma> d
<lekma> is that correct
<lekma> ?
<lekma> johannesV, reinhard:
<lekma> that would be great to be able to use abort() and message() in external python scripts
<lekma> if there is a way to do it, plz let me know
*** thesandroid has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<johannesV_> lekma, abort () is bound into a procedure's namespace. but i'm not sure if you can reach this in code you import into the same namespace
<johannesV_> will have to test it; do you have a ready-to-use testcase ?
<dimas> johannesV_: nothing work without joins :(
<johannesV_> dimas, i know, that's why i've commented out those lines in GDataSource.py ... but doing this you won't be able to insert/update/delete records
<johannesV_> as i've said, we have to wait for reinhard .... at least i'd like to talk to him first, before changing something
<dimas> but at least appserver starts
<johannesV_> :)
<johannesV_> dimas, i'm sure we can fix this problem tomorrow
<johannesV_> lekma, abort () is not available to imported namespaces atm. we'd need to bind it into the __builtins__ in order to do this ...
<johannesV_> but i'd have to verify this first ...
<johannesV_> meanwhile you could pass the session instance via parameter (this would give you at least access to 'message')
<johannesV_> i think we should consider a method 'bindBuiltin ()' in the language-adapters ExecutionContext-class
*** holycow has quit IRC
<johannesV_> hmm, but wait ... there should be an 'abort' bound into the context's local namespace
<johannesV_> erm, no, that's not the same namespace ...
<johannesV_> lekma, i've created a fix to the language-adapter, making abort () a builtin
*** Egyptian[Home] has quit IRC
<johannesV_> will double-check first
*** SachaS has quit IRC
<ajmitch> johannesV_: is there any good reason why navigator imports pstats?
<johannesV_> that's for profiling ... or better for evaluating profile-data, isn't it ?
<ajmitch> python-profiler is under a non-free license
<johannesV_> ajmitch, pstats is only imported, never used
<ajmitch> ok
<ajmitch> I suggest it not be imported then :)
<johannesV_> at least it looks like that at first sight
<johannesV_> right
<ajmitch> that's what I thought
<johannesV_> i agree
<ajmitch> GBaseApp.py in common also uses it in one place
<johannesV_> well, there is an option --profile
<ajmitch> yes
<johannesV_> which uses the propfiler
<ajmitch> and I don't think you can legally link with pstats
<ajmitch> s/link with/import/
<johannesV_> hmm, but isnt there a deb python-profiler
<ajmitch> in non-free
<johannesV_> ah, ok
<ajmitch> it was recently moved there :)
<johannesV_> right, i know as i've missed it ...
*** thesandroid has quit IRC
<ajmitch> ok, I'll just patch gnue-navigator for now :)
*** johannesV_ has quit IRC
*** lekma has quit IRC
*** sjc has quit IRC
*** dcmwai_ has quit IRC
*** cilkay has quit IRC
*** sjc has joined #gnuenterprise
*** dfc has joined #gnuenterprise
*** nickr has quit IRC
*** nickr has joined #gnuenterprise
*** sjc has quit IRC
*** cilkay has joined #gnuenterprise
*** dfc has quit IRC
*** jcater has joined #gnuenterprise
*** dimas has quit IRC
*** jcater has quit IRC
*** dimas has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** derek has joined #gnuenterprise