*** holy_cow has quit IRC
*** Amorphous has joined #gnuenterprise
*** Amorphous has quit IRC
*** Amorphous has joined #gnuenterprise
*** Amorphous has quit IRC
*** johannesV has joined #gnuenterprise
*** Amorphous has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> good morning
<johannesV> good morning btami
*** kilo has joined #gnuenterprise
<kilo> good morning
<soda> good morning all
*** sjc has joined #gnuenterprise
<johannesV> hi kilo, hi soda
<soda> hello
<soda> im soo lazy today
<soda> god bless today its friday
*** dcmwai has quit IRC
<kilo> soda: what do the <-- and --> buttons do on your form?
<soda> kilo: just next/prev record
<soda> i was wandering , it is possible to not render the buttons in main window
<kilo> ah, ok. and where do you use runForm?
<soda> sorry form my english
<soda> kilo: right now nowhere, because i wanted this colours section me in separated form
<kilo> yes, it is possible, place this in form code:
<soda> but i done it in this way
<kilo>   <trigger type="ON-STARTUP" name="Trigger1">
<kilo>     form.setFeature('GUI:MENUBAR:SUPPRESS', 1)
<kilo>     form.setFeature('GUI:TOOLBAR:SUPPRESS', 1)
<kilo>     form.setFeature('GUI:STATUSBAR:SUPPRESS', 1)
<kilo>   </trigger>
<kilo> 
<soda> oki thanks
<kilo> ah, i see
<soda> but now i will have to make runForm for each colour
<soda> coz i have many datas connected to this possition in database
<kilo> johannesV: do you have time/are you willing to take a look at hotline/stammdaten.gfd?
<johannesV> what's the matter with that ?
<kilo> latest svn. first page works ok. i try to store a country, and uopn pushing commit button:
<kilo> Traceback (most recent call last):
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/geasSessionManager.py", line 139, in commit
<kilo>     s.commit ()
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/geasSession.py", line 288, in commit
<kilo>     self.__connection.commit ()
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/data.py", line 670, in commit
<kilo>     resultSet.current.setField (field, value)
<kilo>  AttributeError: 'NoneType' object has no attribute 'setField'
<kilo> Product page also
* johannesV phone
<johannesV> back
<johannesV> wow, this sounds crazy ..
<johannesV> well, and indeed it is ... ?!
<johannesV> hmm
<johannesV> hmm, i think i've an idea where to search ...
<kilo> reinhard should (tm) this 'hmm' 8-))
<johannesV> you know 'wickie' (from tv) ? *lol*
<johannesV> my idea was not good ... :(
<johannesV> kilo, this is not special to hotline
<johannesV> as i can reproduce it in sample.gfd (second tab too)
<johannesV> it looks like you have found a serious bug ... but i can't tell more about atm ...
<johannesV> still searching ...
<kilo> ah oh. it is in fact a little bit bad feeling, playing Lucifer every time, reporting bugs always... 8-))
<kilo> re wickie: dunno who is that
<johannesV> kilo, wickie is a little boy always knowing a solution to nearly all possible problems ... *lol* it's a cartoon we've watched when we've been boys ...
<johannesV> and when he started with a new *great* idea he always said: hmm
<kilo> hmmm, i remember watching 'magilla gorilla', always ending with: 'will try again next week'
<johannesV> kilo, i've tracked it down into appserver: the new record on the second page has definitely a wrong 'state'
<kilo> is it good news?
<johannesV> can't tell right now
<johannesV> ok, i think it's a problem in forms then
<dimas> good morning
<johannesV> kilo: i've found it
<johannesV> but it is still very tricky ... :)
<johannesV> hi dimas
<kilo> hi dimas
<kilo> johannesV: great
<johannesV> kilo, the problem is in forms: GFObjects/GFBlock.py in processCommit ()
<dimas> hello johannesV, kilo
<johannesV> here one block after the other posts it's changes *and* calling a datasourcelink.commit ()
<johannesV> but since the first block (namly blkPerson) is doing a commit *before* the post of the second block has sent it's changes to appserver
<johannesV> appserver has to *destroy* the initialy created instance of address_country for example
<johannesV> the next 'post' of address_country (from the second block/page) leads to a wrong record-state  (=changed)
<johannesV> in appserver, so there's no "insert" but a "update" of a 'non-existent' record
<kilo> i see
<johannesV> as i've changed form's behaviour of a 'rollback' i think we need this for commit too
*** sjc has quit IRC
<johannesV> dimas, i've got a question about GFObjects/GFBlock.py
<dimas> ok
<johannesV> in revision 4146 you've changed the commit () function of GFBlock
<johannesV> instead of self._form.commit () you changed it to call self.processCommit ()
<dimas> kilo: thanks for answering yesterday's questions :)
<johannesV> can you remember why ? since i think this is wrong (what about changes in other non-related blocks ? they're simply lost)
<dimas> exactly it could be tracked on via backlog on that date
<dimas> but forms had strange behaviour
<dimas> without that
<dimas> johannesV: can't look into right now, be back in two hours
<johannesV> hmm, acutally calling "block.commit ()" is somehow "paradox" anyway
<johannesV> since commit () ends a transaction and theirfore should be called on form-level
<johannesV> (since a form can have multiple non-related blocks all having changes belonging to the *same* transaction)
<dimas> from memory i wanted block.commit to work properly, but it was coupled somehow with commiting the whole form
<johannesV> and donig a blkFoo.commit () will loose all changes in the other blocks
<dimas> yes
<dimas> bbl
<johannesV> so to me, blkFoo.commit () should give a depreciation warning
<kilo> shouldn't a block.commit commit changes on the datasource it is connected to, and not bother with other blocks?
<johannesV> right, but the commit is called in processCommit of the block
<kilo> (if it is not detail in a M/D)
<johannesV> this means if you have two blocks (unrelated) from the same "connection" !!! you call the commit on the connection twice
<johannesV> and this means, the first commit does *not* enclose pending changes from the second block into the *same* transaction
<kilo> is stammdaten.gfd using one connection?
<johannesV> of course: appserver
<johannesV> all datasources are sharing the same connection (as they are supposed to do so)
<kilo> oh, sorry, i mixed up connection/datasource...
<johannesV> np
<kilo> so the commit happens on a connection, not on a datasource?
<johannesV> but the sense of a transaction is to have multiple changes in multiple datasources as "one" thing
<johannesV> not yet, but it should be the case
*** dcmwai has joined #gnuenterprise
<johannesV> kilo, meanwhile i've fixed the first problem but encountered another one
<kilo> hmmm, should we call that a success? 8-)))))
<johannesV> yes, i think so
<johannesV> since the commit () problem needed a solution anyway
<johannesV> the way commit () is working atm is wrong in any case (as i see things) in two- and three-tier mode
<kilo> hmm, we are thinking along here with btami, and come to the question: why does block.commit exist?
<johannesV> great!
<btami> lol
<johannesV> this show's me that you are thinking the same way as reinhard and me :)
* kilo looks at gnue-invoice and horrifies himself: there are tons of block commits there...
<kilo> january 7. ideal day for a seppuku...
<johannesV> well, kilo, you have to look closer on all forms having multiple unrelated blocks
<johannesV> all these won't work fine atm (but not because of appserver, but forms)
<johannesV> what is 'seppuku' ?
<kilo> harakiri
<johannesV> oh ...
* btami envisiones kilo making harakiri with a block.commit()
<kilo> well, the key word here is 'unrelated'. M/D blocks are not unrelated
<johannesV> yeah, otherwise he waits until nobody is looking and then runs a form.rollback ()
<johannesV> *lol*
<johannesV> right
<johannesV> M/D is 'related' :)
<kilo> well, i care for hygiene, so take a lot of alcohol with me before. it would be horroristic if my wounds ended up having zillions of viruses and bacteri...
<kilo> 'dear doctor, you know, i had this little harakiri the last week, and my wounds hurt'
<johannesV> hmm, seems as if we need another change in appservers data.py ...
<johannesV> kilo, seems like i've a working copy now ...
<johannesV> but since i've changed appserver too, i do need a lot more testing now
<kilo> hacking data.py is... candy...
<johannesV> well, before you kicked me with your bug i was on my way into data.py anyway (to implement dirty reads)
<kilo> in fact i would like to use this hotline for my own purposes...
<johannesV> but now i think i've to create 'stable' data.py *before* adding dirty-read-stuff into it ...
<kilo> after some customization on forms and reports
*** reinhard has joined #gnuenterprise
<johannesV> ah
<johannesV> there he is
<reinhard> oh
<johannesV> reinhard, i need to change data.py as we have already discussed
* reinhard hides
<johannesV> to only remove those tuples (table,row) which has been processed
<johannesV> i mean keeping all that "initialized" ones
<reinhard> change in forms doesn't help?
<johannesV> not completely, example: sample.gfd
<johannesV> add a new 'country', and press commit
<johannesV> this works fine after changing forms
<johannesV> but, now change the person and try to commit again ....
<johannesV> you'll get a 'instance 123545.... is not valid'
<johannesV> why ? well, it's quite easy
<johannesV> the commit has stored the person-instance, and recognized it's empty
<reinhard> gotcha
<johannesV> so it has been thrown away and a new one was created (automatically by appserver db-driver)
<johannesV> the next is the change of the country
<johannesV> which does this insert but also destroys the newly created person-instance
<johannesV> (which breaks reference for appserver db-driver)
<johannesV> maybe the order might differ a bit but it's the big picture
<SachaS> hallo johannesV
<johannesV> hi SachaS
<SachaS> du hast einen names verwandten bekommen :)
<johannesV> reinhard, how shall we proceed with changing data.py (wrt dirty-read stuff)
<johannesV> SachaS, yeah i've seen it. my congratulations !
<reinhard> johannesV: you've already started with dirty reads?
<johannesV> well, SachaS, i count on you to make sure he can finish the work on gnue in about 20 years if i'm retired :)
<reinhard> lol
<kilo> @channelstats stats johannesV
<johannesV> SachaS, so we can simulate continuous work :)
*** dcmwai has quit IRC
<johannesV> maybe i should change my nick to be only 'johannes' then
<johannesV> reinhard, yes i did so but it's not very much
<johannesV> so i could revert that changes
<reinhard> johannesV: then please just go on
<reinhard> we will *always* find a new bug that stops us from starting with new function if we want
<reinhard> as we agreed this problem has been there for several months now and nobody noticed
<johannesV> reinhard, but this means appserver/forms with multiple unrelated blocks is not working at all atm
<johannesV> that's right, hmm
<reinhard> and it only appears if there *are* unrelated blocks in one form (w/o m/d)
<johannesV> ok, so i'll continue with dirty reads and include the fixed mentioned before
<reinhard> which seems to be a very rare case anyway
<johannesV> shall i commit the fix to forms ?
<johannesV> or do we discuss it first with jamest ?
<johannesV> (maybe the latter one would be no bad thing)
<reinhard> I think yes, and we would ask jamest/jcater to look at the commit today afternoon
<reinhard> it's easier to discuss when the commit is already out
<kilo> it also appears in gnue-invoice, when a subform is committed, closed, and you get back to the riginal, calling form...
<reinhard> johannesV: but as you like
<reinhard> you can also hold back the commit
<johannesV> kilo, a subform is *not* a new transaction !
<kilo> child form
<johannesV> but having multiple forms their own 'session' is something i'd like to have in the todo-list
<johannesV> kilo, that's the same
<kilo> ok, wasnt sure 'subform' was good naming
<johannesV> if you call a new form from another one and do a commit in that form, it's still a single transaction as seen by the backend (if you're using appserver)
<reinhard> also if you use 2-tier
<reinhard> a transaction is a transaction is a transaction
<johannesV> but in this case the blocks are really 'unrelated' :)
<johannesV> right
<johannesV> ok, i'll look how much time i can spend to gnue this weekend, so maybe i'll do commits if i'm done with it
<btami> Traceback (most recent call last):
<btami>    File "/home/tamas/svn/gnue/.cvsdevelbase/gnue/appserver/geasSessionManager.py", line 185, in load
<btami>     return s.load (classname, obj_id_list, propertylist)
<btami>    File "/home/tamas/svn/gnue/.cvsdevelbase/gnue/appserver/geasSession.py", line 463, in load
<btami>     instance = self.__findInstance (classdef, object_id, propertylist)
<btami>    File "/home/tamas/svn/gnue/.cvsdevelbase/gnue/appserver/geasSession.py", line 408, in __findInstance
<btami>     raise InstanceNotFoundError, (classdef.fullName, object_id)
<btami>  InstanceNotFoundError: A 'INV_Head' osztály '16047863865370549475526249647194' példánya nem található
<btami> from gnue-invoice
<btami> after adding new customer, close subform
<johannesV> that looks much like the bug i've fixed right now
<btami> selecting the new one
<btami> oh
<btami> may try svn up ?
<johannesV> btami, no i haven't commited yet
<btami> ok, have to go home
<btami> bbl
*** btami has quit IRC
*** SachaS has quit IRC
*** lekma has joined #gnuenterprise
<lekma> hi everyone
*** kilo has quit IRC
<reinhard> hi lekma
<dimas> back
*** kilo has joined #gnuenterprise
<lekma> reinhard: did you change recently OnValidate semantic??
<lekma> it still should be trigerred whenever i create or modify a class object
<lekma> ie ( a db record)
<lekma> ??
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
<lekma> cause we have a strange situation here where an onvalidate is fired normally in certain case and not in others
<lekma> :(
<reinhard> lekma: we did not change OnValidate semantic in a while
<reinhard> last change IIRC was to first fire OnValidate and later check for non-nullable fields
<reinhard> however you can currently fool OnValidate with a trick:
<kilo> lekma: it did not change recently
<reinhard> OnValidate is not guaranteed to be called for changes that are done in OnValidate
<reinhard> that is
<reinhard> if in OnValidate of class a you change objects of class b
<reinhard> OnValidate of class b might or might not get called
<reinhard> fixing this is also on our TODO list
<lekma> OnValidate of class b might or might not get called <-- why is that??
<reinhard> however it might be not too easy as we have to prevent circular OnValidate calling
<lekma> cause i think we're in this case
<reinhard> when you call commit
<reinhard> appserver builds a list of all objects that have been changed
<reinhard> and calls OnValidate on all objects of that list
<reinhard> so objects that haven't been changed before that but are changed by OnValidate are not in the list
<reinhard> if you look at geasSession.py
<reinhard>     for instance in self.__dirtyInstances.values ():
<reinhard>       instance.validate ()
<reinhard> it should be possible to do something like
<reinhard> while self.__dirtyInstances:
<reinhard>   key = self.__dirtyInstances.keys () [0]
<reinhard>   (self.__dirtyInstances [key]).validate ()
<reinhard>   del self.__dirtyInstances [key]
<reinhard> ---
<reinhard> instead of the existing 2 lines
<reinhard> as a quick fix
<lekma> reinhard: ok i'll try this
<reinhard> however this might cause appserver to loop forever if a.OnValidate changes b and b.OnValidate changes a
<kilo> typical deadlock, yeaahhh
<reinhard> so the really correct solution would be to add the keys that were processed to a list and check no key is processed twice
<reinhard> and if it tries to process it again, raise an exception
<lekma> reinhard: one small hint (maybe)
<lekma> it seems we're in this situation when b.OnValidate is fired from a.OnValidate, when a existed already but was changed
<lekma> when a is new a.OnValidate creates b that fires b.OnValidate correctly
<lekma> but when a already exist
<lekma> and is changed
<lekma> a.OnValidate creates b, but b.OnValidate is not fired
<lekma> (which is strange cause b is correctly created)
<reinhard> can you try with the change i listed above?
<reinhard> like I said as a temporary fix
<lekma> i will in 5 mins
<reinhard> ok thanks
*** jamest has joined #gnuenterprise
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** kilo has quit IRC
<lekma> reinhard: ok the fix you gave me works for the case we had, thx (from frances also)
<reinhard> thanks for testing
<reinhard> I think you can leave that fix there for you
<reinhard> until we do the proper fix
*** johannesV_ has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** johannesV has quit IRC
*** titopbs has joined #gnuenterprise
<dimas> reinhard: what about base_currency in luca? is it completed?
<dimas> i need to track history of dollars and euro
<dimas> rates to local currency
<reinhard> dimas: i was thinking about that
<dimas> do i need more classes? 1 to define names and codes of currencies and 2 to keep history to particular date
<reinhard> for many small business users it would be overkill, so i delayed it
<reinhard> my approach would have been to have 1 class to define name and code
<reinhard> and another class as a detail to currency class
<reinhard> that defines the values with a starting date
<reinhard> probably also change the calculation procedures in the currency class to access the values for the correct date
<reinhard> (would need another parameter for the procedure with the date then
<reinhard> also, if you look at the currency class, I'm not 100% confident if the rounding is particularly smart the way I do it
<dimas> base_currency seems suitable if i need today's value
<reinhard> right
<dimas> hm, seems ok for the beginning
<dimas> history could be handled by another class
<dimas> reinhard: and i need gl even in its simple and early form, i could test it on daily basis but i need some thing to be explained
<dimas> strange as i tent to choose dollar as a base local currency
<reinhard> hehe
<reinhard> dimas: to use gl is a bit too early, it's not much more as a proof of concept as it stands now
<reinhard> but i seriously hope to have the time to continue work on it in the next days
<reinhard> bbl
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
<lekma> bbl
*** lekma has quit IRC
*** SachaS has joined #gnuenterprise
<johannesV_> great, dirty-reads seem to work
<johannesV_> at least the first test-run ended successfully ... :)
<dimas> lekla would be glad
<johannesV_> yes, i know :)
<johannesV_> but i think this change would need extensive testing first ...
<dimas> how it could be tested on sample or own forms?
<johannesV_> hmm, it looks really good ... which makes me nervouse
<johannesV_> since the actual change took be about 10 minutes ...
<johannesV_> this looks far too easy and there must be a drawback somewhere ..
<johannesV_> i'll better discuss some testcases with reinhard first ... :)
<johannesV_> using a language-interface-app doing: find ('foo'), new ('foo'), find ('foo') behaves properly, where the second find includes the newly created instance
<johannesV_> hmm, there is a side-effect we haven't thought of by now (i think)
<johannesV_> doing a 'post' of all pending changes just before a new query is performed (like a find)
<johannesV_> these data will be available to following finds () without beeing validated !
<johannesV_> this is because OnValidate is fired by the session's commit () function
<johannesV_> but we cannot simply move the OnValidate, can we ?
*** dcmwai has joined #gnuenterprise
<johannesV_> bbl
*** dcmwai has quit IRC
<reinhard> I think it is obvious that uncommitted data is also unvalidated
<reinhard> but it's important that people are aware of that
<mnemoc> uhm
<mnemoc> i think it in the opossite way
<mnemoc> if validations fails it can't be commited
<mnemoc> but /me == noone
<mnemoc> rb
<mnemoc> brb*
*** wendall911 has joined #gnuenterprise
*** SachaS has quit IRC
<johannesV_> .,,,mmmmmmmmmmmmmmmmmmmöööl.,,
* johannesV_ thinks his little daughter should work a bit on her spelling ... :)
<reinhard> lol
<reinhard> sounded like a burp
*** SachaS has joined #gnuenterprise
*** titopbs has quit IRC
<johannesV_> right :)
<johannesV_> mnemoc, this does not interfere with commit
<johannesV_> if an OnValidate fails, no commit will happen
<johannesV_> the point is the time when OnValidate get's executed
<johannesV_> a find in the same session can access dirty data (as determined by the name: dirty read)
<johannesV_> after thinking about i came to the same conclusion as reinhard
<johannesV_> it's ok, but programmers have to be aware of that
<johannesV_> btw. i've fixed that annoying bug in forms, where a intercepted commit (f.e. if an onValidate fails) leaved forms in a not-responding state :)
<johannesV_> but still a big question atm is finding a 'good' test-cycle for all this stuff regarding dirty reads and (somehow connected) multiple unrelated blocks
<johannesV_> i'll change to another (more comfortable) workstation now ...
<johannesV_> bbl
*** johannesV_ has quit IRC
<SachaS> i would suggest u guys look at unit testing
<SachaS> there is just so much suff that can be broken
*** neilt has joined #gnuenterprise
<reinhard> off for today
<reinhard> bye
*** reinhard has left #gnuenterprise
*** neilt has quit IRC
*** neilt has joined #gnuenterprise
<neilt> /msg  NickServ help identify
*** Amorphous has quit IRC
*** neilt has quit IRC
*** sjc has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** Amorphous has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** kilo has quit IRC
*** jamest has left #gnuenterprise
*** apropos has joined #gnuenterprise
*** gnardo has joined #gnuenterprise
*** jcater has quit IRC
*** holycow has quit IRC
*** dcmwai has joined #gnuenterprise
*** sjc has quit IRC
*** holycow has joined #gnuenterprise
*** titopbs has quit IRC
*** wt has joined #gnuenterprise
*** wendall911 has quit IRC
*** cilkay has left #gnuenterprise
*** holycow has quit IRC