New proteus library to access Tryton's models like a client

[paepke, 2010-05-24 10:50:42]

What does it mean "like a client"? What is the difference to using netrpc?

[ced, 2010-05-24 10:54:09]

On 2010/05/24 10:50:42, paepke wrote:
> What does it mean "like a client"? What is the difference to using netrpc?

netrpc is just a protocol.
"like a client" means like tryton.

[paepke, 2010-05-24 11:36:21]

On 2010/05/24 10:54:09, ced wrote:
> On 2010/05/24 10:50:42, paepke wrote:
> > What does it mean "like a client"? What is the difference to using netrpc?
> 
> netrpc is just a protocol.
> "like a client" means like tryton.

how does tryton it? i don't understand the concept of this library. or  for what
is is good for.

[ced, 2010-05-24 11:56:17]

On 2010/05/24 11:36:21, paepke wrote:
> On 2010/05/24 10:54:09, ced wrote:
> > On 2010/05/24 10:50:42, paepke wrote:
> > > What does it mean "like a client"? What is the difference to using netrpc?
> > 
> > netrpc is just a protocol.
> > "like a client" means like tryton.
> 
> how does tryton it? i don't understand the concept of this library. or  for
what
> is is good for.

My main goals is to be able make write test scenario at business level.

[udono, 2010-05-24 16:19:51]

On 2010/05/24 11:56:17, ced wrote:
> On 2010/05/24 11:36:21, paepke wrote:
> > On 2010/05/24 10:54:09, ced wrote:
> > > On 2010/05/24 10:50:42, paepke wrote:
> > > > What does it mean "like a client"? What is the difference to using
netrpc?
> > > netrpc is just a protocol.
> > > "like a client" means like tryton.
> > how does tryton it? i don't understand the concept of this library. or  for
> what
> > is is good for.
> My main goals is to be able make write test scenario at business level.

This sounds very interesting to me. Some questions remaining:
1. Can you give a more concrete examples for the later use? Will proteus be able
to evaluate field contents delivered from trytond like the tryton client? I have
already seen test_model and test_config, but these are not on 'business level'. 
2. Do you mean with 'business level' tests which targets the direction I started
with http://codereview.appspot.com/818046 ?
3. Are you planning to use some BDD-like higher level API ?

[udono, 2010-05-28 07:46:55]

http://codereview.appspot.com/1205045/diff/39001/40006
File proteus/__init__.py (right):

http://codereview.appspot.com/1205045/diff/39001/40006#newcode43
proteus/__init__.py:43: # TODO call on_change
yeah, this would be great!

http://codereview.appspot.com/1205045/diff/39001/40007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/39001/40007#newcode48
proteus/config.py:48: def __init__(self, database_name, user, database_type):
put here:
language='en_US'

http://codereview.appspot.com/1205045/diff/39001/40007#newcode56
proteus/config.py:56: from trytond.tools import Cache
why not put the imports on module level, in the beginning of the file?

http://codereview.appspot.com/1205045/diff/39001/40007#newcode59
proteus/config.py:59: self.database_type = database_type
self.language = language

http://codereview.appspot.com/1205045/diff/39001/40007#newcode70
proteus/config.py:70: create(database_name, CONFIG['admin_passwd'], 'en_US', '')
create(database_name, CONFIG['admin_passwd'], language, '')

[ced, 2010-05-28 07:50:43]

http://codereview.appspot.com/1205045/diff/39001/40007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/39001/40007#newcode48
proteus/config.py:48: def __init__(self, database_name, user, database_type):
On 2010/05/28 07:46:55, udono wrote:
> put here:
> language='en_US'

No, language is defined on the user.

http://codereview.appspot.com/1205045/diff/39001/40007#newcode56
proteus/config.py:56: from trytond.tools import Cache
On 2010/05/28 07:46:55, udono wrote:
> why not put the imports on module level, in the beginning of the file?

To have only trytond as optional dependency.

[udono, 2010-05-28 08:06:00]

http://codereview.appspot.com/1205045/diff/39001/40007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/39001/40007#newcode48
proteus/config.py:48: def __init__(self, database_name, user, database_type):
On 2010/05/28 07:50:44, ced wrote:
> On 2010/05/28 07:46:55, udono wrote:
> > put here:
> > language='en_US'
> No, language is defined on the user.
But the problem is on create databases. You have to update the language for all
modules. So having a 
create_db_lang='en_US'
would be good. Or is there another way to load other languages from inside
proteus without restaring and updating all modules of the server?

[ced, 2010-05-28 09:43:41]

http://codereview.appspot.com/1205045/diff/39001/40007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/39001/40007#newcode48
proteus/config.py:48: def __init__(self, database_name, user, database_type):
On 2010/05/28 08:06:00, udono wrote:
> On 2010/05/28 07:50:44, ced wrote:
> > On 2010/05/28 07:46:55, udono wrote:
> > > put here:
> > > language='en_US'
> > No, language is defined on the user.
> But the problem is on create databases. You have to update the language for
all
> modules. So having a 
> create_db_lang='en_US'
> would be good. Or is there another way to load other languages from inside
> proteus without restaring and updating all modules of the server?
> 
I think I will move the database creation outside this function

[bch, 2010-06-02 09:46:03]

http://codereview.appspot.com/1205045/diff/54001/55007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/54001/55007#newcode98
proteus/config.py:98: def set_trytond(database_name, user='admin',
database_type='postgresql',
I think that the name 'backend' would be better than 'database_type', because
when an *rpc backend will be available we will do something like:

database_type="server:8070"

http://codereview.appspot.com/1205045/diff/54001/55007#newcode103
proteus/config.py:103: return
This doesn't allow to connect with one user and after to connect with another,
so I'm forced to quit the python shell and relaunch it (and to loose all my
stuffs).

More importantly: because CONFIG is global, this prevent to use several user or
database at the same time. It would be more powerful to have an api like:

adm_local = proteus.connect('dev', 'admin', 'postreql')
dem_distant = proteus.connect('prod', 'demo', 'server:8070')

and then play/transfer/compare with records from both connections.


Another solution is to mix both behaviour:

proteur.connect(..) just populate a global CONFIG (so its easier for simple
usage, but:

local_env = proteus.Proteus()
local_env.connect(...)

will populate local_env.CONFIG. Bottle (http://bottle.paws.de) provides this
kind of behavior and it works well.

[ced, 2010-06-03 18:22:40]

http://codereview.appspot.com/1205045/diff/54001/55007
File proteus/config.py (right):

http://codereview.appspot.com/1205045/diff/54001/55007#newcode98
proteus/config.py:98: def set_trytond(database_name, user='admin',
database_type='postgresql',
On 2010/06/02 09:46:03, bch wrote:
> I think that the name 'backend' would be better than 'database_type', because
> when an *rpc backend will be available we will do something like:
> 
> database_type="server:8070"

Of course not. The signature of set_xmlrpc will be different.

http://codereview.appspot.com/1205045/diff/54001/55007#newcode103
proteus/config.py:103: return
On 2010/06/02 09:46:03, bch wrote:
> This doesn't allow to connect with one user and after to connect with another,
> so I'm forced to quit the python shell and relaunch it (and to loose all my
> stuffs).

The goals is to behave like the client. And you can not login with two user.

> 
> More importantly: because CONFIG is global, this prevent to use several user
or
> database at the same time. It would be more powerful to have an api like:
> 
> adm_local = proteus.connect('dev', 'admin', 'postreql')
> dem_distant = proteus.connect('prod', 'demo', 'server:8070')
> 
> and then play/transfer/compare with records from both connections.
> 

This is not the initial goal and I don't think this is really useful in real
environment.

> 
> Another solution is to mix both behaviour:
> 
> proteur.connect(..) just populate a global CONFIG (so its easier for simple
> usage, but:
> 
> local_env = proteus.Proteus()
> local_env.connect(...)
> 
> will populate local_env.CONFIG. Bottle (http://bottle.paws.de) provides this
> kind of behavior and it works well. 

I don't see any example.

[bch, 2010-06-04 07:54:13]

On 2010/06/03 18:22:40, ced wrote:
> http://codereview.appspot.com/1205045/diff/54001/55007
> File proteus/config.py (right):
> 
> http://codereview.appspot.com/1205045/diff/54001/55007#newcode98
> proteus/config.py:98: def set_trytond(database_name, user='admin',
> database_type='postgresql',
> On 2010/06/02 09:46:03, bch wrote:
> > I think that the name 'backend' would be better than 'database_type',
because
> > when an *rpc backend will be available we will do something like:
> > 
> > database_type="server:8070"
> 
> Of course not. The signature of set_xmlrpc will be different.

Ok I didn't knew there will be several set_* fct.
Btw 'set_tryton' is misleading, the name suggest that it only store the options,
but actually if the database does not exist it will be created (maybe it should
be an other arg like "create=True").


> > More importantly: because CONFIG is global, this prevent to use several user
> or
> > database at the same time. It would be more powerful to have an api like:
> > 
> > adm_local = proteus.connect('dev', 'admin', 'postreql')
> > dem_distant = proteus.connect('prod', 'demo', 'server:8070')
> > 
> > and then play/transfer/compare with records from both connections.
> > 
> 
> This is not the initial goal and I don't think this is really useful in real
> environment.

Several useful use-cases:

1) multi-threaded web interface,
2) To use as a "tryton shell", to help developers,
3) To write higher level tests.

If you don't care about this it's ok, but currently if someone need something
like that he can not even use proteus as a base for a new tool, so he will need
to re-develop something very similar.


> > 
> > Another solution is to mix both behaviour:
> > 
> > proteur.connect(..) just populate a global CONFIG (so its easier for simple
> > usage, but:
> > 
> > local_env = proteus.Proteus()
> > local_env.connect(...)
> > 
> > will populate local_env.CONFIG. Bottle (http://bottle.paws.de) provides this
> > kind of behavior and it works well. 
> 
> I don't see any example.

[bch, 2010-06-07 10:35:14]

On 2010/06/06 12:49:23, ced wrote:
> 

I like this new version, because now i can do: 

cfg1 = config.set_trytond(...)
cfg2 = config.set_trytond(...)

User1 = Model.get('ir.ui.menu', cfg1)
User2 = Model.get('ir.ui.menu', cfg2)

.. etc ..

But it also means that _CONFIG does not need to be thread-safe anymore, because
each thread can now keep a reference of the config and pass it to Model.get().

On the other hand, maybe it's better to handle threads inside proteus, so there
is less risk of errors to use it in a threaded environment (works out of the
box, simpler api).

Anyway, all my previous concerns are now gone.