Should be keep the multitenant feature even if broken?

[Jacques Le Roux]

Hi,

After my analysis at https://s.apache.org/hvR9 if we don't fix the issues reported there I wonder if we don't need to remove the multitenant feature,
better not to propose a broken solution!

Jacques

[taher]

In my opinion, the multi-tenancy feature can be reasonably replaced with
non-java databases like mysql and postgres combined with docker. Both
instances share the same code base but with two different runtime volumes
and two databases. This would actually reduce the complexity of the code
base, especially the entity engine.

On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <[hidden email]>
wrote:

> Hi,
>
> After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
> reported there I wonder if we don't need to remove the multitenant feature,
> better not to propose a broken solution!
>
> Jacques
>
>

[Jacques Le Roux]

Thanks Taher,

IMO if we do that we should document clearly how to do it, before dropping and cleaning the multi-tenancy feature.

Of course solving the 2 issues reported in OFBIZ-9230 (checkRhsType and getSystemPropertyValue) should be tried before. I'll not create Jiras for that
before we get to a consensus

Jacques


Le 03/03/2017 à 13:22, Taher Alkhateeb a écrit :

> In my opinion, the multi-tenancy feature can be reasonably replaced with
> non-java databases like mysql and postgres combined with docker. Both
> instances share the same code base but with two different runtime volumes
> and two databases. This would actually reduce the complexity of the code
> base, especially the entity engine.
>
> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> Hi,
>>
>> After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
>> reported there I wonder if we don't need to remove the multitenant feature,
>> better not to propose a broken solution!
>>
>> Jacques
>>
>>

[Michael Brohl-3]

Hi Taher,

I don't think that this is a valid short-term approach.

As far as I know, there are users and also service providers relying on
the multi-tenant feature and we should have a mid- to long-term roadmap
for a migration to other solutions.

It would be really helpful to have some opinions by users of the
multi-tenancy feature.

Best regards,

Michael


Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:

> In my opinion, the multi-tenancy feature can be reasonably replaced with
> non-java databases like mysql and postgres combined with docker. Both
> instances share the same code base but with two different runtime volumes
> and two databases. This would actually reduce the complexity of the code
> base, especially the entity engine.
>
> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> Hi,
>>
>> After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
>> reported there I wonder if we don't need to remove the multitenant feature,
>> better not to propose a broken solution!
>>
>> Jacques
>>
>>

[taher]

All good points Michael. Replacing is neither short term nor easy as many
places in the code base depend on this feature, not to mention the need for
community approval too. I just mentioned this as an alternative solution
from a technical standpoint.

So our best bet is to fix the issue mentioned by Jacques.

On Mar 3, 2017 9:16 PM, "Michael Brohl" <[hidden email]> wrote:

> Hi Taher,
>
> I don't think that this is a valid short-term approach.
>
> As far as I know, there are users and also service providers relying on
> the multi-tenant feature and we should have a mid- to long-term roadmap for
> a migration to other solutions.
>
> It would be really helpful to have some opinions by users of the
> multi-tenancy feature.
>
> Best regards,
>
> Michael
>
>
> Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:
>
>> In my opinion, the multi-tenancy feature can be reasonably replaced with
>> non-java databases like mysql and postgres combined with docker. Both
>> instances share the same code base but with two different runtime volumes
>> and two databases. This would actually reduce the complexity of the code
>> base, especially the entity engine.
>>
>> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>> Hi,
>>>
>>> After my analysis at https://s.apache.org/hvR9 if we don't fix the
>>> issues
>>> reported there I wonder if we don't need to remove the multitenant
>>> feature,
>>> better not to propose a broken solution!
>>>
>>> Jacques
>>>
>>>
>>>
>
>

[Rishi Solanki]

I dig into the issue and proposed one solution in the same Jira ticket
OFBIZ-9230. Please see if it looks fine or may be we can proceed in that
direction.

Quick Reference from ticket: "In the template/FTL context or in the screen
context whenever we get the delegator as null we can use this delegatorName
first from session and if it is empty then we could try to use default
delegator."

Thanks!


Rishi Solanki
Sr. Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Sat, Mar 4, 2017 at 1:13 AM, Taher Alkhateeb <[hidden email]>
wrote:

> All good points Michael. Replacing is neither short term nor easy as many
> places in the code base depend on this feature, not to mention the need for
> community approval too. I just mentioned this as an alternative solution
> from a technical standpoint.
>
> So our best bet is to fix the issue mentioned by Jacques.
>
> On Mar 3, 2017 9:16 PM, "Michael Brohl" <[hidden email]> wrote:
>
> > Hi Taher,
> >
> > I don't think that this is a valid short-term approach.
> >
> > As far as I know, there are users and also service providers relying on
> > the multi-tenant feature and we should have a mid- to long-term roadmap
> for
> > a migration to other solutions.
> >
> > It would be really helpful to have some opinions by users of the
> > multi-tenancy feature.
> >
> > Best regards,
> >
> > Michael
> >
> >
> > Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:
> >
> >> In my opinion, the multi-tenancy feature can be reasonably replaced with
> >> non-java databases like mysql and postgres combined with docker. Both
> >> instances share the same code base but with two different runtime
> volumes
> >> and two databases. This would actually reduce the complexity of the code
> >> base, especially the entity engine.
> >>
> >> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <
> [hidden email]>
> >> wrote:
> >>
> >> Hi,
> >>>
> >>> After my analysis at https://s.apache.org/hvR9 if we don't fix the
> >>> issues
> >>> reported there I wonder if we don't need to remove the multitenant
> >>> feature,
> >>> better not to propose a broken solution!
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >
> >
>

[Jacques Le Roux]

Thanks for your ideas Rishi,

Fixed with OFBIZ-9230

I had a look at checkRhsType() but that's another beast. Because AFAIK the delegator only misses when checkRhsType is called indirectly from the
JobPoller.

It begins to miss in this line in selectCountByCondition()

makeConditionWhereString(sqlBuffer, " WHERE ", modelEntity, whereEntityCondition, viewWhereConditions, whereEntityConditionParams);

I have created OFBIZ-9249, it's minor but not trivial!

Jacques


Le 04/03/2017 à 15:07, Rishi Solanki a écrit :

> I dig into the issue and proposed one solution in the same Jira ticket
> OFBIZ-9230. Please see if it looks fine or may be we can proceed in that
> direction.
>
> Quick Reference from ticket: "In the template/FTL context or in the screen
> context whenever we get the delegator as null we can use this delegatorName
> first from session and if it is empty then we could try to use default
> delegator."
>
> Thanks!
>
>
> Rishi Solanki
> Sr. Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>
> On Sat, Mar 4, 2017 at 1:13 AM, Taher Alkhateeb <[hidden email]>
> wrote:
>
>> All good points Michael. Replacing is neither short term nor easy as many
>> places in the code base depend on this feature, not to mention the need for
>> community approval too. I just mentioned this as an alternative solution
>> from a technical standpoint.
>>
>> So our best bet is to fix the issue mentioned by Jacques.
>>
>> On Mar 3, 2017 9:16 PM, "Michael Brohl" <[hidden email]> wrote:
>>
>>> Hi Taher,
>>>
>>> I don't think that this is a valid short-term approach.
>>>
>>> As far as I know, there are users and also service providers relying on
>>> the multi-tenant feature and we should have a mid- to long-term roadmap
>> for
>>> a migration to other solutions.
>>>
>>> It would be really helpful to have some opinions by users of the
>>> multi-tenancy feature.
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>>
>>> Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:
>>>
>>>> In my opinion, the multi-tenancy feature can be reasonably replaced with
>>>> non-java databases like mysql and postgres combined with docker. Both
>>>> instances share the same code base but with two different runtime
>> volumes
>>>> and two databases. This would actually reduce the complexity of the code
>>>> base, especially the entity engine.
>>>>
>>>> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <
>> [hidden email]>
>>>> wrote:
>>>>
>>>> Hi,
>>>>> After my analysis at https://s.apache.org/hvR9 if we don't fix the
>>>>> issues
>>>>> reported there I wonder if we don't need to remove the multitenant
>>>>> feature,
>>>>> better not to propose a broken solution!
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>

[Rishi Solanki]

Thanks Jacques!


--
Rishi Solanki
Sr. Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Wed, Mar 8, 2017 at 3:37 PM, Jacques Le Roux <
[hidden email]> wrote:

> Thanks for your ideas Rishi,
>
> Fixed with OFBIZ-9230
>
> I had a look at checkRhsType() but that's another beast. Because AFAIK the
> delegator only misses when checkRhsType is called indirectly from the
> JobPoller.
>
> It begins to miss in this line in selectCountByCondition()
>
> makeConditionWhereString(sqlBuffer, " WHERE ", modelEntity,
> whereEntityCondition, viewWhereConditions, whereEntityConditionParams);
>
> I have created OFBIZ-9249, it's minor but not trivial!
>
> Jacques
>
>
>
> Le 04/03/2017 à 15:07, Rishi Solanki a écrit :
>
>> I dig into the issue and proposed one solution in the same Jira ticket
>> OFBIZ-9230. Please see if it looks fine or may be we can proceed in that
>> direction.
>>
>> Quick Reference from ticket: "In the template/FTL context or in the screen
>> context whenever we get the delegator as null we can use this
>> delegatorName
>> first from session and if it is empty then we could try to use default
>> delegator."
>>
>> Thanks!
>>
>>
>> Rishi Solanki
>> Sr. Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: [phone]
>> http://www.hotwaxsystems.com
>>
>> On Sat, Mar 4, 2017 at 1:13 AM, Taher Alkhateeb <
>> [hidden email]>
>> wrote:
>>
>> All good points Michael. Replacing is neither short term nor easy as many
>>> places in the code base depend on this feature, not to mention the need
>>> for
>>> community approval too. I just mentioned this as an alternative solution
>>> from a technical standpoint.
>>>
>>> So our best bet is to fix the issue mentioned by Jacques.
>>>
>>> On Mar 3, 2017 9:16 PM, "Michael Brohl" <[hidden email]>
>>> wrote:
>>>
>>> Hi Taher,
>>>>
>>>> I don't think that this is a valid short-term approach.
>>>>
>>>> As far as I know, there are users and also service providers relying on
>>>> the multi-tenant feature and we should have a mid- to long-term roadmap
>>>>
>>> for
>>>
>>>> a migration to other solutions.
>>>>
>>>> It would be really helpful to have some opinions by users of the
>>>> multi-tenancy feature.
>>>>
>>>> Best regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>> Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:
>>>>
>>>> In my opinion, the multi-tenancy feature can be reasonably replaced with
>>>>> non-java databases like mysql and postgres combined with docker. Both
>>>>> instances share the same code base but with two different runtime
>>>>>
>>>> volumes
>>>
>>>> and two databases. This would actually reduce the complexity of the code
>>>>> base, especially the entity engine.
>>>>>
>>>>> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" <
>>>>>
>>>> [hidden email]>
>>>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> After my analysis at https://s.apache.org/hvR9 if we don't fix the
>>>>>> issues
>>>>>> reported there I wonder if we don't need to remove the multitenant
>>>>>> feature,
>>>>>> better not to propose a broken solution!
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>