RE: OFBiz Multi-tenancy

Mike, You are right that postgres out of the box does not provide this solution but you can still achieve this by: 1. Setup a hot standby server (through WAL logs) 2. When a table is dropped on master at time x, replay the standby server to time y just before the table was dropped. 3. pg_dump

Re: OFBiz Multi-tenancy

t von unterwegs mit BlackBerry® Webmail. -Original Message- From: Pierre Smits Date: Thu, 27 Feb 2014 12:57:54 To: Reply-To: user@ofbiz.apache.org Subject: Re: OFBiz Multi-tenancy Hi all, Thank you for submitting links to documents related to the subject. Of course, for each the criteria

Re: OFBiz Multi-tenancy

>>Mysql allows PITR at the DB level, where postgresql is an all/nothing (i.e.ALL databases) PITR recovery. So, if you want to do multi-tenant on a >big gigantic DB server, the way to go is mysql. >Mike, you have probably missed an important feature of Postgres (Write-ahead logging) which is >year

RE: OFBiz Multi-tenancy

I was not aware that mail man forbids html display. This table is distorted in plain text emails. It can be viewed here: http://cloudcomputing.sys-con.com/node/1610582 Regards: Ejaz Ahmed > From: ejaz_ah...@outlook.com > To: user@ofbiz.apache.org > Subject: RE: OFBiz Mult

RE: OFBiz Multi-tenancy

Poor Looking at above VS chart, it is clear that separate database is going to fit the requirements of ofbiz. Regards: Ejaz Ahmed > Subject: Re: OFBiz Multi-tenancy > To: user@ofbiz.apache.org > From: c.schin...@gmail.com > Date: Thu, 27 Feb 2014 12:31:06 + > >

Re: OFBiz Multi-tenancy

Multi-tenancy Hi all, Thank you for submitting links to documents related to the subject. Of course, for each the criteria might vary and weigh differently, and the options available in current feature set of OFBiz are limited. But in whole, the cost of operations are key. These cost of operations

Re: OFBiz Multi-tenancy

Hi all, Thank you for submitting links to documents related to the subject. Of course, for each the criteria might vary and weigh differently, and the options available in current feature set of OFBiz are limited. But in whole, the cost of operations are key. These cost of operations not only in

RE: OFBiz Multi-tenancy

>Shared Database and Shared Schema initially sounds great, until you realize >what a pain it will be to do backups/restores of individual tenants. > Eventually, a tenant will mess up it's data and will ask you to restore back > to date/time. Now you are in a real pickle, unless each tenant has i

Re: OFBiz Multi-tenancy

ee...@gmail.com] > Sent: Wednesday, February 26, 2014 2:12 PM > To: user > Subject: Re: OFBiz Multi-tenancy > > Shared Database and Shared Schema initially sounds great, until you > realize what a pain it will be to do backups/restores of individual tenants. > Eventually, a ten

RE: OFBiz Multi-tenancy

@gmail.com] Sent: Wednesday, February 26, 2014 2:12 PM To: user Subject: Re: OFBiz Multi-tenancy Shared Database and Shared Schema initially sounds great, until you realize what a pain it will be to do backups/restores of individual tenants. Eventually, a tenant will mess up it's data and

Re: OFBiz Multi-tenancy

Here is another interesting tidbit regarding restoring to Point-In-Time recovery (PITR) --and-- databases. Mysql allows PITR at the DB level, where postgresql is an all/nothing (i.e. ALL databases) PITR recovery. So, if you want to do multi-tenant on a big gigantic DB server, the way to go is mys

Re: OFBiz Multi-tenancy

Thanks Mike, That's indeed an interesting perspective! Jacques Le 26/02/2014 20:12, Mike a écrit : Shared Database and Shared Schema initially sounds great, until you realize what a pain it will be to do backups/restores of individual tenants. Eventually, a tenant will mess up it's data and

Re: OFBiz Multi-tenancy

Shared Database and Shared Schema initially sounds great, until you realize what a pain it will be to do backups/restores of individual tenants. Eventually, a tenant will mess up it's data and will ask you to restore back to date/time. Now you are in a real pickle, unless each tenant has it's own

Re: OFBiz Multi-tenancy

The simplest way to share would be to create a Jira issue. Actually we even defined a procedure some years ago: 1) Discuss intial requirements and such in the dev ML d...@ofbiz.apache.org 2) When settled create * either a specific page in Confluence wiki (due to spam, you need now to ask for

Re: OFBiz Multi-tenancy

Thank You Pierre Smits and Jacques. I really appreciate Jacques sharing the link. To answer Pierre Smits *(**What would you expect the not-so-typical tenant to have?)* The most common SaaS plan will be 5 users for a tenant. The maximum users for a tenant will be approximately 100. In case we take

Re: OFBiz Multi-tenancy

No Pierre, you are not mistaken, only separate DB by tenant is implemented in OFBiz Prashant, I'd recommend this article as reference for implementing another way http://msdn.microsoft.com/en-us/library/aa479086.aspx HTH Jacques Le 26/02/2014 14:14, Pierre Smits a écrit : Hi Prashant, Scal

Re: OFBiz Multi-tenancy

Hi Prashant, Scaling up your setup to tens of thousands of tenants must be surely a long term goal. Even when considering the number of users being between 1 to 10 for any typical tenant. What would you expect the not-so-typical tenant to have? So, as to you questions: Re 1. Yes, there are others

OFBiz Multi-tenancy

Hello OFBizers, I am evaluating a proposal for development of a SaaS application using OFBiz framework. As I understood from wiki page for every tenant a separate data instance is created. The requirement for us is to be able

Re: OFBiz multi-tenancy.

Hi, the patch made for neogia is avalaible at this address : http://issues.apache.org/jira/browse/OFBIZ-2020 HTH, Le 02/08/2009 21:37, David E Jones a écrit : ../.. -- - Erwan -

Re: OFBiz multi-tenancy.

ing are the cases for which we are looking OFBiz as multi- tenat module : 1) Number of tenants in application are fixed. 2) Number of database server are fixed. 3) All tenants share the same application and they can't change the application. I have read all the thread about OFBiz Mult

OFBiz multi-tenancy.

1) Number of tenants in application are fixed. 2) Number of database server are fixed. 3) All tenants share the same application and they can't change the application. I have read all the thread about OFBiz Multi tenancy implementation on OFBiz mailing list, but didn't get any prope