*** johannesV has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> good morning
*** kilo has joined #gnuenterprise
<dimas> good morning
<dimas> kilo: are you guys using location module you wrote?
*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<dimas> good morning reinhard
<kilo> dimas: not yet but may happen
<dimas> i need to step out of flat schema with something like address1 address2 fields
<dimas> not feel not ready to step too far :)
<dimas> but feel
<dimas>   <class name="Zip" comment="">
<dimas>     <property name="code"       type="string(8)"    nullable="False"    comment="zip code" />
<dimas>     <property name="city"       type="string(70)"                       comment="Full name of city"
<dimas> kilo: there could be many zip codes to one city
<dimas> how is that suitable for you?
<johannesV> i think you will have to reenter the same city-name again and again ...
<johannesV> so you might want to have a city-class and another one providing the valid zip-codes :)
<dimas> i will not like that
<johannesV> but maybe you just don't like that normalization
<dimas> city should be in a separate class for me definitely
<reinhard> dimas: even several cities can share a common zip code, at least here where I live
<btami> dimas: kilo just went to customer...
<dimas> reinhard: then how would you do that for your local situation?
<dimas> and general
<reinhard> Most programs I know do not normalize postal code and city
<reinhard> it's just 2 fields
<reinhard> some of them have a table where they get initial values for city when given postal code
<reinhard> so you enter postal code, then the program fills the city field, but then you can still change it
<dimas> i see
*** yure has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** chillywi1ly has joined #gnuenterprise
*** chillywilly has quit IRC
*** ajmitch_ has joined #gnuenterprise
*** ajmitch has quit IRC
*** btami has quit IRC
*** jamest has joined #gnuenterprise
*** chillywi1ly is now known as chillywilly
*** kilo has left #gnuenterprise
*** docelic has joined #gnuenterprise
*** yure has quit IRC
*** jason__ has joined #gnuenterprise
*** jason__ is now known as jcater
*** derek has joined #gnuenterprise
*** klasstek has joined #gnuenterprise
*** sacha has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<reinhard> cu all
*** reinhard has quit IRC
*** kilo has quit IRC
*** jcater has quit IRC
*** jason__ has joined #gnuenterprise
*** johannesV_ has quit IRC
*** jason__ has quit IRC
*** jason__ has joined #gnuenterprise
*** jason__ is now known as jcater
*** jcater has quit IRC
*** sjc has joined #gnuenterprise
*** jason__ has joined #gnuenterprise
*** jason__ is now known as jcater
*** docelic has quit IRC
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** yure has quit IRC
*** kilo has joined #gnuenterprise
<kilo> reinhard: if i know the gnue_id of an object, is it a must to do a find(...)[0] to get access to it?
<reinhard> hmmm
<reinhard> let me look
<reinhard> get (classname, objectId)
<kilo> oh, is there something like that?
<kilo> nice
<kilo> any limitations?
<reinhard>  — Method on session: get (classname, objectId)
<reinhard> Returns the existing instance of the class classname that has a gnue_id of objectId. If no such instance exists, an exception is raised.
<reinhard> [from the appserver developer's guide] ;-)
<reinhard> objectId must exist
<kilo> :( i was looking at the API docs
<reinhard> the API docs are not interesting unless you want to build your own non-Python client
<kilo> i see
<reinhard> (like lekma and siesel do)
<kilo> thx
<reinhard> but I agree it should be made more clear in that document
<reinhard> apart from the fact that the API doc is completely out of sync with the code anyway :-(
<kilo> :(
<reinhard> btw
<reinhard> it would be session.get()
<reinhard> not just get
<reinhard> just like, btw, find() and new() and message() are actually methods of session
<reinhard> and only available as global procedures for compatibility reasons
<reinhard> having them as methods of session has the big advantage of being able to just pass session to a external procedure
<kilo> but inside a gcd, in a procedure which notation should one use?
<reinhard> and having all those find() and new() etc available
<reinhard> I tend to use session.find
<reinhard> but I still use just find() a lot
<reinhard> I try to get used to use the session. way
<kilo> ok i see
<reinhard> fwiw, I have created a new issue for the interbase commit problem and a related problem on sqlite
<kilo> checking
<reinhard> I have put you on nosy, so actually you should have received a copy
<kilo> oh ok, just arrived ;)
<kilo> This new learning amazes me, Sir Bedemir. Explain again how sheeps' bladders may be employed to prevent earthquakes...
*** jamest has left #gnuenterprise
<reinhard> kilo: huh?
<reinhard> should this remind me of some Monty Python?
<kilo> bingo :)
<reinhard> cu all
*** reinhard has quit IRC
*** jcater has quit IRC
*** klasstek has quit IRC
*** jason__ has joined #gnuenterprise
*** jason__ has quit IRC
*** jcater has joined #gnuenterprise
*** kilo has quit IRC
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** sjc has quit IRC
*** sacha_ has joined #gnuenterprise