flask-tryton: multiple databases

[marsu...@gmail.com]

Is it possible to use flask-tryton on multiple databases ?

I'd like to select the database to use according to the request's host name.

[Cédric Krier]

On 07 Jul 15:05, marsu...@gmail.com wrote:
> Is it possible to use flask-tryton on multiple databases ?

No, you have to use different application with different configuration.

> I'd like to select the database to use according to the request's host name.

You should probably no rely too much on the multi-database support of
Tryton, it will be removed one day.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[marsu...@gmail.com]

On Tuesday, July 8, 2014 12:18:10 AM UTC+2, Cédric Krier wrote:

You should probably no rely too much on the multi-database support of
Tryton, it will be removed one day.

u kidding ?

what is the rationale behind this planned? change ?

 

[Cédric Krier]

On 08 Jul 01:31, marsu...@gmail.com wrote:
> On Tuesday, July 8, 2014 12:18:10 AM UTC+2, Cédric Krier wrote:
> >
> > You should probably no rely too much on the multi-database support of
> > Tryton, it will be removed one day.
> >
> >
> u kidding ?

Not at all and I think it will come faster than you can expect.

> what is the rationale behind this planned? change ?

Already talked about on
https://groups.google.com/d/msg/tryton-contrib/h2-4NCI_nLM/m19zRXiNrkEJ

But mainly because it is useless, it adds complexity, it slows Tryton,
it is a wrong attempt for database management, it prevents to do some
great stuff with the framework (like: adding new field type with module,
add new protocols on the fly)

[marsu...@gmail.com]

On Tuesday, July 8, 2014 10:52:48 AM UTC+2, Cédric Krier wrote:

Not at all and I think it will come faster than you can expect.

Do you have a roadmap or even a simple todo list containing those revolutionary planned changes ?

If tryton allows only one database per deployment. How would one scale hundreds of databases on the same servers ?

I'm evaluating tryton for a saas service, nothing concrete so far but I'm concerned about this change you are talking about so I'd like to know what would be the impact.

 

But mainly because it is useless, it adds complexity, it slows Tryton,
it is a wrong attempt for database management, it prevents to do some
great stuff with the framework (like: adding new field type with module,
add new protocols on the fly) 

 

Would this change allow us to have a "base model" ?

cf my previous question here:

https://groups.google.com/forum/#!searchin/tryton-dev/marchal/tryton-dev/oqyOKTQJhIk/mG_QGWFbtbEJ

[Cédric Krier]

On 08 Jul 06:23, marsu...@gmail.com wrote:
> On Tuesday, July 8, 2014 10:52:48 AM UTC+2, Cédric Krier wrote:
> >
> > Not at all and I think it will come faster than you can expect.
> >
>
> Do you have a roadmap or even a simple todo list containing those
> revolutionary planned changes ?

Yes simple:

- drop multidatase

> If tryton allows only one database per deployment. How would one scale
> hundreds of databases on the same servers ?

By running hundred of trytond.

[marsu...@gmail.com]

On Tuesday, July 8, 2014 3:34:21 PM UTC+2, Cédric Krier wrote:

> Do you have a roadmap or even a simple todo list containing those
> revolutionary planned changes ?

Yes simple:

    - drop multidatase 

Shall I understand this is the only upcoming major change in the framework ?

 

[Cédric Krier]

Who knows…

[marsu...@gmail.com]

On Tuesday, July 8, 2014 9:32:33 PM UTC+2, Cédric Krier wrote:

> > > Do you have a roadmap or even a simple todo list containing those
> > > revolutionary planned changes ?
> >
> > Yes simple:
> >
> >     - drop multidatase
>
>
> Shall I understand this is the only upcoming major change in the framework ?

Who knows…

Thank you for that helpful and valuable information about the future of Tryton.

You make it easy to choose a framework.

[Cédric Krier]

Ok you want it.
Tryton is a free software project developed by a small community of
volunteer.
Developers work on what ever they want, they are not forced to work on
any specific topic. So nobody can tell what will be developed in Tryton
more than what is already done (and probably published as patch). So if
you are looking for a roadmap, you are at the wrong place. Tryton will
evolve following what those people will put in it, that's all.

[marsu...@gmail.com]

On Tuesday, July 8, 2014 10:15:29 PM UTC+2, Cédric Krier wrote:

Developers work on what ever they want, they are not forced to work on
any specific topic. So nobody can tell what will be developed in Tryton
more than what is already done (and probably published as patch). So if
you are looking for a roadmap, you are at the wrong place.

I was not talking about a roadmap of new features but a roadmap (or todo list) of features to be removed (such as multi-database support).

[Cédric Krier]

Something added or something removed, it is the same. It is an
improvement and they fail on the same workflow.

[Sharoon Thomas]

On Jul 9, 2014, at 3:41 AM, Cédric Krier <cedric...@b2ck.com> wrote:

> On 08 Jul 14:14, marsu...@gmail.com wrote:
>> On Tuesday, July 8, 2014 10:15:29 PM UTC+2, Cédric Krier wrote:
>>>
>>> Developers work on what ever they want, they are not forced to work on
>>> any specific topic. So nobody can tell what will be developed in Tryton
>>> more than what is already done (and probably published as patch). So if
>>> you are looking for a roadmap, you are at the wrong place.
>>>
>>
>> I was not talking about a roadmap of new features but a roadmap (or todo
>> list) of features to be removed (such as multi-database support).
>
> Something added or something removed, it is the same. It is an
> improvement and they fail on the same workflow.
>

That being said, I am not sure that removing multiple-database support is
a “improvement” that has wider acceptance.

I personally feel its a step backward. Multi-database support has been a
critical advantage of tryton and we use it for a variety of reasons from having a
demo/playground database in the same environment for users to try things
safely along with production database to having multi-tenant systems.

From the previous discussion about the topic and the available information I
don’t see why multi-database support should be removed. If creating and
dropping databases is the issue, we should remove that instead.

My 2¢

Thanks & Regards


Sharoon Thomas
CEO & Chief Software Architect
Openlabs Technologies & Consulting (P) Limited

w: http://www.openlabs.co.in
m: +1 813.793.6736 (OPEN) Extn. 200
t: @sharoonthomas

- We win when our customers win

[Albert Cervera i Areny]

2014-07-09 5:47 GMT+02:00 Sharoon Thomas <sharoon...@openlabs.co.in>:
>
>
> On Jul 9, 2014, at 3:41 AM, Cédric Krier <cedric...@b2ck.com> wrote:
>
> > On 08 Jul 14:14, marsu...@gmail.com wrote:
> >> On Tuesday, July 8, 2014 10:15:29 PM UTC+2, Cédric Krier wrote:
> >>>
> >>> Developers work on what ever they want, they are not forced to work on
> >>> any specific topic. So nobody can tell what will be developed in Tryton
> >>> more than what is already done (and probably published as patch). So if
> >>> you are looking for a roadmap, you are at the wrong place.
> >>>
> >>
> >> I was not talking about a roadmap of new features but a roadmap (or todo
> >> list) of features to be removed (such as multi-database support).
> >
> > Something added or something removed, it is the same. It is an
> > improvement and they fail on the same workflow.
> >
>
> That being said, I am not sure that removing multiple-database support is
> a “improvement” that has wider acceptance.
>
> I personally feel its a step backward. Multi-database support has been a
> critical advantage of tryton and we use it for a variety of reasons from having a
> demo/playground database in the same environment for users to try things
> safely along with production database to having multi-tenant systems.
>
> From the previous discussion about the topic and the available information I
> don’t see why multi-database support should be removed. If creating and
> dropping databases is the issue, we should remove that instead.

What I've read so far, dropping multi-database support has the
following advantages:

- Can solve a security issue (details not available for those without
access to security issues)
- Allows creating new field types in modules
- Allows adding new protocols in modules
- Simplifies the code base
- Allows improving the usage of maps/paths with WSGI (don't know the details)

On the other hand I don't personally see many problems with removing
the feature because:

- Tryton client has profiles which make it easy for the user to change
from one server to another, so demo/playground database should not be
a problem, I think
- Multi-tenant systems should be easy to implement with other tools,
maybe the only issue is that you'll need some more resources because
you'll have several trytond processes but I guess you need that anyway
if you want to provide a decent service

Also, as you already said, database management can be removed because:

- It means we have to deal with some issues with Tryton locking
template1 and disallowing the creation of new databases
- Dumping/restoring databases does not scale

>
> My 2¢
>
> Thanks & Regards
>
>
> Sharoon Thomas
> CEO & Chief Software Architect
> Openlabs Technologies & Consulting (P) Limited
>
> w: http://www.openlabs.co.in
> m: +1 813.793.6736 (OPEN) Extn. 200
> t: @sharoonthomas
>
> - We win when our customers win
>

--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

[Cédric Krier]

On 09 Jul 09:17, Sharoon Thomas wrote:
>
> On Jul 9, 2014, at 3:41 AM, Cédric Krier <cedric...@b2ck.com> wrote:
>
> > On 08 Jul 14:14, marsu...@gmail.com wrote:
> >> On Tuesday, July 8, 2014 10:15:29 PM UTC+2, Cédric Krier wrote:
> >>>
> >>> Developers work on what ever they want, they are not forced to work on
> >>> any specific topic. So nobody can tell what will be developed in Tryton
> >>> more than what is already done (and probably published as patch). So if
> >>> you are looking for a roadmap, you are at the wrong place.
> >>>
> >>
> >> I was not talking about a roadmap of new features but a roadmap (or todo
> >> list) of features to be removed (such as multi-database support).
> >
> > Something added or something removed, it is the same. It is an
> > improvement and they fail on the same workflow.
> >
>
> That being said, I am not sure that removing multiple-database support is
> a “improvement” that has wider acceptance.

It is in the core developpers (the people who maintains that shit).

> I personally feel its a step backward. Multi-database support has been a
> critical advantage of tryton and we use it for a variety of reasons from having a
> demo/playground database in the same environment for users to try things
> safely along with production database to having multi-tenant systems.

You think it is safety but it is not at all.
You don't playground on the production server if you don't want
problems.
Let's just imagine, you use the same trytond instance for production and
some testing. Your testing is going crazy and eat all the CPU or is
blocking on some IO then your production is stopped.

> From the previous discussion about the topic and the available information I
> don’t see why multi-database support should be removed. If creating and
> dropping databases is the issue, we should remove that instead.

It is the all concept the problem.
Also it prevents to have trytond to scale correctly, to have more
features (see previous post) etc.

[Guillem Barba Domingo]

El 09/07/2014 9:26, "Albert Cervera i Areny" <alb...@nan-tic.com> va escriure:

>
> 2014-07-09 5:47 GMT+02:00 Sharoon Thomas <sharoon...@openlabs.co.in>:
> >
> > On Jul 9, 2014, at 3:41 AM, Cédric Krier <cedric...@b2ck.com> wrote:
> >
> > > On 08 Jul 14:14, marsu...@gmail.com wrote:
> > >> On Tuesday, July 8, 2014 10:15:29 PM UTC+2, Cédric Krier wrote:
> > >>>
> > >>> Developers work on what ever they want, they are not forced to work on
> > >>> any specific topic. So nobody can tell what will be developed in Tryton
> > >>> more than what is already done (and probably published as patch). So if
> > >>> you are looking for a roadmap, you are at the wrong place.
> > >>>
> > >>
> > >> I was not talking about a roadmap of new features but a roadmap (or todo
> > >> list) of features to be removed (such as multi-database support).
> > >
> > > Something added or something removed, it is the same. It is an
> > > improvement and they fail on the same workflow.
> > >
> >
> > That being said, I am not sure that removing multiple-database support is
> > a “improvement” that has wider acceptance.
> >
> > I personally feel its a step backward. Multi-database support has been a
> > critical advantage of tryton and we use it for a variety of reasons from having a
> > demo/playground database in the same environment for users to try things
> > safely along with production database to having multi-tenant systems.
> >
> > From the previous discussion about the topic and the available information I
> > don’t see why multi-database support should be removed. If creating and
> > dropping databases is the issue, we should remove that instead.
>
> What I've read so far, dropping multi-database support has the
> following advantages:
>

> - (...)

> - Allows improving the usage of maps/paths with WSGI (don't know the details)
>
> On the other hand I don't personally see many problems with removing
> the feature because:
>

> - (...)

> - Multi-tenant systems should be easy to implement with other tools,
> maybe the only issue is that you'll need some more resources because
> you'll have several trytond processes but I guess you need that anyway
> if you want to provide a decent service

With the WSGI support and Circus (for example) have a multiprocess (to serve multiple databases) should be easy and more flexible and powerful to implement something like DB selection by subdomain.

[Bernard Bouchat]

On Wednesday, July 9, 2014 9:26:01 AM UTC+2, Albert Cervera i Areny wrote:

What I've read so far, dropping multi-database support has the
following advantages:

- Can solve a security issue (details not available for those without
access to security issues)
- Allows creating new field types in modules
- Allows adding new protocols in modules
- Simplifies the code base
- Allows improving the usage of maps/paths with WSGI (don't know the details) 

and also it is faster if understand good.

and I also think it's best for security. technical client ask if other client is on the same server and they don't want a system with shared business.

for which version can we hope to have this multiple database removed with custom fields?

is there a branch to test?

I can't help with the code but I can help to test !