Daniel,
your suggestion does make sense; that's for sure. I got the impression
that this hasn't been a topic yet as OFBiz has obviously not yet been
discovered by hosting providers. (Well, it has! We're one and we're
looking at it.)
I have no clue yet about the architecture of OFBiz, so I just cannot
comment on a technical implementation of proper virtual hosting, but IMO
it would make sense to plan for different approaches, as they will be
needed depending on the situation.
a) Name based virtual hosting, as you described:
> domain1.com uses database1
> domain2.com uses database2
> etc.
b) Just put a drop-down with availabe databases onto the login screen.
This would for example make it quite easy for any internal setup within
a company to have a QA and a production database without the need to
create two different domains for that.
c) (Might be a problem): Have a user login and determine from the user's
profile to what organisation (=database) she or he belongs and then
maybe display a list of databases available.
The problem with c) is that I understand users are in the database, so
this is kind of a chicken and egg problem. One solution might be to make
users use email style usernames, such as [EMAIL PROTECTED] where domain
determines the database to connect to.
> The challenge I see is that this will involve moving company
> configuration information and e-mail templates from various system
> files to somewhere else, or into the database.
Where does this stuff live today? IMO it should be in a "save place"
anyway, i.e. under a separate tree in the filesystem to make sure you
can upgrade the OFBiz code without loosing your customizations.
Maybe someone who knows the code better than me could come up with a
place to start and look for a hook to make any of this happen. Would be
a nice exercise in getting aquainted with OFBiz internals.
I am not sure if this discussion belongs to the dev list, though?
Regards,
Torsten
Daniel Kunkel schrieb:
Hi
Has anyone given serious consideration to creating a virtual database
redirector, so:
domain1.com uses database1
domain2.com uses database2
etc.
At the beginning of the request, the correct database connection is
selected, and everything that uses that connection will automatically be
connected to the correct database.
A technique like this is especially useful in that it would only
requires one instance of the OFBiz code, making hosting multiple OFBiz
business more feasible, and keeps each database separate so it would be
easy to move customers from server to server as necessary.
The challenge I see is that this will involve moving company
configuration information and e-mail templates from various system files
to somewhere else, or into the database.
Daniel
On Tue, 2006-11-14 at 16:19 -0800, Si Chen wrote:
I agree. Separate instances with separate databases is the best way,
technically and from a business perspective.
On Nov 14, 2006, at 2:23 PM, Sebastian Schirmer wrote:
Hi Torsten,
I think the best way is to separate ofbiz instances with different
databases. You can use the apache mod_jk with mutliple ajp workers
on different ports to separate the ofbiz instances. We have a
production environment running two instances of the same host.
best regards Sebastian
--On Sonntag, 12. November 2006 19:05 +0100 Torsten Schlabach
<[EMAIL PROTECTED]> wrote:
Hi all!
We are in the process of setting up OFBiz and we're currently
investigating the possibility of becoming a hosting provider for
OZBiz.
So we would want to rent out OFBiz to a number of customers who are
entirely unrelated to each other.
My question therefore is:
- Should we have a completely separate database for each customer
- or would it be possible to define silos or some kind of virtual
chinese walls withtin in the same database for different, unrelated
customers.
Please note that I am not looking at different legal entities which
belong to the same group of companies and do business with each
other,
but in theory or customers could be competitors to each other. We
would
therefore need to be 100% sure that customer A will never ever see
any
data from customer B.
Is OFBiz designed in a way to support this or would separate
databases
the clean and or recommended way of doing this?
Regards,
Torsten
Best Regards,
Si
[EMAIL PROTECTED]
