any others are
> > all able to track the last time you said hello to your special friend and
> > recommend you step into the closest flower shop by running some sort of
> > monolithic natured multi-tenant software.
> >
> >
> > Carlos
> >
> >
>
) and many others are
> all able to track the last time you said hello to your special friend and
> recommend you step into the closest flower shop by running some sort of
> monolithic natured multi-tenant software.
>
>
> Carlos
>
>
> -----Original Message-
> From: P
recommend you
step into the closest flower shop by running some sort of monolithic natured
multi-tenant software.
Carlos
-Original Message-
From: Paul Mandeltort [mailto:p...@marcospec.com]
Sent: Friday, September 7, 2018 1:27 PM
To: user@ofbiz.apache.org
Subject: Re: Should we kee
; From: Gil Portenseigne [mailto:gil.portensei...@nereide.fr]
> Sent: Friday, September 7, 2018 11:07 AM
> To: user@ofbiz.apache.org
> Subject: Re: Should we keep the multi-tenants feature in OFBiz?
>
> Hello,
>
> Very nice analysis, I got the same feeling about multi-t
]
Sent: Friday, September 7, 2018 11:07 AM
To: user@ofbiz.apache.org
Subject: Re: Should we keep the multi-tenants feature in OFBiz?
Hello,
Very nice analysis, I got the same feeling about multi-tenancy, and prefer
using separate instances encapsulated within VM.
Gil
Le mardi 04 sept. 2018 à 19
Hello,
Very nice analysis, I got the same feeling about multi-tenancy, and prefer
using
separate instances encapsulated within VM.
Gil
Le mardi 04 sept. 2018 à 19:12:20 (+0300), Taher Alkhateeb a écrit :
> The question is: is it worth keeping it? To answer this question,
> perhaps we need to
Hi there,
On Tue, 4 Sep 2018, Taher Alkhateeb wrote:
... The multi-tenancy feature in OFBiz is making nearly every
critical artifact in the system complex. It is hard wired in tomcat,
components, data loaders and many other places. I stopped counting
the "if" conditions to handle the
Thanks Taher for sharing your thoughts,
This remembers me I once referenced an article from 2006[1]that I can resist to resurrect because I believe the analysis there is still relevant and
complete yours.
It's no longer available but in web.archive.org[2]
Like other threads I recently
I was referring to a situation where multi tenancy was not used
Original Message
Subject: Re: Should we keep the multi-tenants feature in OFBiz?
From: Taher Alkhateeb
Date: Tue, September 04, 2018 9:23 pm
To: user@ofbiz.apache.org
The automation of multi tenancy setup could
ean every tenant has their
> own install of OFbiz, their own install of Postgres SQL, and their own
> server farm?
>
> Original Message
> Subject: Re: Should we keep the multi-tenants feature in OFBiz?
> From: Taher Alkhateeb
> Date: Tue, September 04,
So if you don't have multi-tenancy does that mean every tenant has their
own install of OFbiz, their own install of Postgres SQL, and their own
server farm?
Original Message
Subject: Re: Should we keep the multi-tenants feature in OFBiz?
From: Taher Alkhateeb
Date: Tue
The question is: is it worth keeping it? To answer this question,
perhaps we need to perhaps look at the pros and cons
pros of keeping multi-tenancy:
- less memory consumption.
- less storage consumption.
- single deployment (less effort)
cons of keeping multi-tenancy:
- Inflexibility: all
My opinion is to just completely ditch the multi tenant code since it seems
to be more trouble than it's worth. Anyone serious about designing a
system to support a similar concept would do it their own way anyway, most
likely using completely separate DBs. Face it, using a common DB and share
Hi,
Note: this conversation started on the dev ML:
https://markmail.org/message/hb2kt5nkodhwnkgw
The multi-tenants feature in OFBiz only allows a dozens or maybe even few
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not
14 matches
Mail list logo
