Seperate tenant entity for entitymodel.xml

[BJ Freeman]

That way the entities will only be loaded when the default delegator is
loaded on install.
there already is a discussion on how to load tenants data that does not
included the demo data for the TenantDemoData.xml
and entry in the ofbiz-componets would reference the tenant entity as
reader=seeddefault

This way the demo data show that those two are only meant for the
default delagator.


=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

[Adam Heath-2]

BJ Freeman wrote:
> That way the entities will only be loaded when the default delegator is
> loaded on install.
> there already is a discussion on how to load tenants data that does not
> included the demo data for the TenantDemoData.xml
> and entry in the ofbiz-componets would reference the tenant entity as
> reader=seeddefault

seed-tenant instead.

>
> This way the demo data show that those two are only meant for the
> default delagator.
>
>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
> Specialtymarket.com <http://www.specialtymarket.com/>
>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>
>

[Adam Heath-2]

Adam Heath wrote:
> BJ Freeman wrote:
>> That way the entities will only be loaded when the default delegator is
>> loaded on install.
>> there already is a discussion on how to load tenants data that does not
>> included the demo data for the TenantDemoData.xml
>> and entry in the ofbiz-componets would reference the tenant entity as
>> reader=seeddefault
>
> seed-tenant instead.

And the ability to let a 'demo' reader include other readers as well.

>
>> This way the demo data show that those two are only meant for the
>> default delagator.
>>
>>
>> =========================
>> BJ Freeman
>> http://bjfreeman.elance.com
>> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
>> Specialtymarket.com <http://www.specialtymarket.com/>
>>
>> Systems Integrator-- Glad to Assist
>>
>> Chat  Y! messenger: bjfr33man
>> Linkedin
>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>
>>
>

[BJ Freeman]

not sure we are on the same page
the reader code is modified to not only looke for are reader specified
(seed, demo, seed-intial,ext) but those readers with the delegator
appended to them.
when the install for the default delegator is done
it will look for seed-default readers, as well as just seed is in the
command line

when a tenant install is done it will ignore readers=seed-default.
but look for seed-[tenantID] when seed is in the commandline


=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Adam Heath sent the following on 4/3/2010 4:25 PM:

> Adam Heath wrote:
>> BJ Freeman wrote:
>>> That way the entities will only be loaded when the default delegator is
>>> loaded on install.
>>> there already is a discussion on how to load tenants data that does not
>>> included the demo data for the TenantDemoData.xml
>>> and entry in the ofbiz-componets would reference the tenant entity as
>>> reader=seeddefault
>> seed-tenant instead.
>
> And the ability to let a 'demo' reader include other readers as well.
>
>>> This way the demo data show that those two are only meant for the
>>> default delagator.
>>>
>>>
>>> =========================
>>> BJ Freeman
>>> http://bjfreeman.elance.com
>>> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat  Y! messenger: bjfr33man
>>> Linkedin
>>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>>
>>>
>
>

[Bob Morley]

Somewhat related, when we implemented our multi-tenant support we  
found a number of places where the "default" delegator was hardcoded  
or assumed. When we had differences in the entity models for our  
deployment delegator vs. tenant delegators these issues surfaced.

I admit I have not yet taken the time to go over david's  
implementation in detail, but an approach where the entity model is  
different from default might lead you down this road (not that it  
would be a bad thing).

Ultimately we got to a place where we had no dependancy on a delegator  
named default at all. Atleast I hope we did :) Would be willing to  
package this up if you see any value.

Bob

On 2010-04-03, at 8:20 PM, BJ Freeman <[hidden email]> wrote:

> not sure we are on the same page
> the reader code is modified to not only looke for are reader specified
> (seed, demo, seed-intial,ext) but those readers with the delegator
> appended to them.
> when the install for the default delegator is done
> it will look for seed-default readers, as well as just seed is in the
> command line
>
> when a tenant install is done it will ignore readers=seed-default.
> but look for seed-[tenantID] when seed is in the commandline
>
>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93 
> >
> Specialtymarket.com <http://www.specialtymarket.com/>
>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro 
> >
>
>
> Adam Heath sent the following on 4/3/2010 4:25 PM:
>> Adam Heath wrote:
>>> BJ Freeman wrote:
>>>> That way the entities will only be loaded when the default  
>>>> delegator is
>>>> loaded on install.
>>>> there already is a discussion on how to load tenants data that  
>>>> does not
>>>> included the demo data for the TenantDemoData.xml
>>>> and entry in the ofbiz-componets would reference the tenant  
>>>> entity as
>>>> reader=seeddefault
>>> seed-tenant instead.
>>
>> And the ability to let a 'demo' reader include other readers as well.
>>
>>>> This way the demo data show that those two are only meant for the
>>>> default delagator.
>>>>
>>>>
>>>> =========================
>>>> BJ Freeman
>>>> http://bjfreeman.elance.com
>>>> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93 
>>>> >
>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>
>>>> Systems Integrator-- Glad to Assist
>>>>
>>>> Chat  Y! messenger: bjfr33man
>>>> Linkedin
>>>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro 
>>>> >
>>>>
>>>>
>>
>>
>
>

[Adam Heath-2]

Robert Morley wrote:
> Somewhat related, when we implemented our multi-tenant support we found
> a number of places where the "default" delegator was hardcoded or
> assumed. When we had differences in the entity models for our deployment
> delegator vs. tenant delegators these issues surfaced.

I fixed a bunch of those recently.  The factory methods that create
values and keys would attempt to initialize the object with

>
> I admit I have not yet taken the time to go over david's implementation
> in detail, but an approach where the entity model is different from
> default might lead you down this road (not that it would be a bad thing).
>
> Ultimately we got to a place where we had no dependancy on a delegator
> named default at all. Atleast I hope we did :) Would be willing to
> package this up if you see any value.
>
> Bob
>
> On 2010-04-03, at 8:20 PM, BJ Freeman <[hidden email]> wrote:
>
>> not sure we are on the same page
>> the reader code is modified to not only looke for are reader specified
>> (seed, demo, seed-intial,ext) but those readers with the delegator
>> appended to them.
>> when the install for the default delegator is done
>> it will look for seed-default readers, as well as just seed is in the
>> command line
>>
>> when a tenant install is done it will ignore readers=seed-default.
>> but look for seed-[tenantID] when seed is in the commandline
>>
>>
>> =========================
>> BJ Freeman
>> http://bjfreeman.elance.com
>> Strategic Power Office with Supplier Automation
>> <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
>> Specialtymarket.com <http://www.specialtymarket.com/>
>>
>> Systems Integrator-- Glad to Assist
>>
>> Chat  Y! messenger: bjfr33man
>> Linkedin
>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>
>>
>>
>> Adam Heath sent the following on 4/3/2010 4:25 PM:
>>> Adam Heath wrote:
>>>> BJ Freeman wrote:
>>>>> That way the entities will only be loaded when the default
>>>>> delegator is
>>>>> loaded on install.
>>>>> there already is a discussion on how to load tenants data that does
>>>>> not
>>>>> included the demo data for the TenantDemoData.xml
>>>>> and entry in the ofbiz-componets would reference the tenant entity as
>>>>> reader=seeddefault
>>>> seed-tenant instead.
>>>
>>> And the ability to let a 'demo' reader include other readers as well.
>>>
>>>>> This way the demo data show that those two are only meant for the
>>>>> default delagator.
>>>>>
>>>>>
>>>>> =========================
>>>>> BJ Freeman
>>>>> http://bjfreeman.elance.com
>>>>> Strategic Power Office with Supplier Automation
>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>>
>>>>> Systems Integrator-- Glad to Assist
>>>>>
>>>>> Chat  Y! messenger: bjfr33man
>>>>> Linkedin
>>>>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>

[Adam Heath-2]

Adam Heath wrote:
> Robert Morley wrote:
>> Somewhat related, when we implemented our multi-tenant support we found
>> a number of places where the "default" delegator was hardcoded or
>> assumed. When we had differences in the entity models for our deployment
>> delegator vs. tenant delegators these issues surfaced.
>
> I fixed a bunch of those recently.  The factory methods that create
> values and keys would attempt to initialize the object with

Bother, that got sent way before I was done.

Anyways, ...

I fixed a bunch of those recently.  The factory methods that create
values and keys would attempt to initialize the object with data.
However, during the create calls, the delegator hadn't been set yet.
so, when the model was queried, it would try to fetch the value's
delegator, which wasn't set.  It would then try to look up the
delegator by name.  Since once hadn't been set yet, it fell back on
"default".

Look at revision 921989.

[Bob Morley]

Will do. I seem to recall that I had to change a number of signatures  
in the entity pkg to float down appropriate context so default would  
not be used. I will dig up my work on Monday and compare to latest  
ofbiz trunk.

Bob

On 2010-04-04, at 12:03 AM, Adam Heath <[hidden email]> wrote:

> Adam Heath wrote:
>> Robert Morley wrote:
>>> Somewhat related, when we implemented our multi-tenant support we  
>>> found
>>> a number of places where the "default" delegator was hardcoded or
>>> assumed. When we had differences in the entity models for our  
>>> deployment
>>> delegator vs. tenant delegators these issues surfaced.
>>
>> I fixed a bunch of those recently.  The factory methods that create
>> values and keys would attempt to initialize the object with
>
> Bother, that got sent way before I was done.
>
> Anyways, ...
>
> I fixed a bunch of those recently.  The factory methods that create
> values and keys would attempt to initialize the object with data.
> However, during the create calls, the delegator hadn't been set yet.
> so, when the model was queried, it would try to fetch the value's
> delegator, which wasn't set.  It would then try to look up the
> delegator by name.  Since once hadn't been set yet, it fell back on
> "default".
>
> Look at revision 921989.
>

[Bob Morley]

Bob Morley wrote

Will do. I seem to recall that I had to change a number of signatures  
in the entity pkg to float down appropriate context so default would  
not be used. I will dig up my work on Monday and compare to latest  
ofbiz trunk.

Adam -- I took a look at the changes that I had put in place and one of the fundamental problems can be seen in EntityExpr -> makeWhereString around line 130 "this.checkRhsType(modelEntity, null);".  The second argument there is meant to be the delegator.  In checkRhsType it has logic to check for a null delegator and if so "we'll cheat a little here and assume the default delegator".  Our issue was that our default delegator database looked quite a bit different from our "tenant" database so we would get into this code and use the wrong delegator and as a result the wrong entity model.

We made a few changes such as ...

- change the signature chain for entity expressions to provide the delegator
- if checkRhsType is called with a null delegator we log a warning message *
- removed default constructor for GenericValue to one that required a delegator
- throw illegal argument exception if GenericDelegator is constructed with a null delegatorName
- creation of GenericValue and GenericPK to require a delegator rather than an anti-pattern of construction and setDelegator pattern.

* I wonder if this should have been changed to an IllegalArgumentException upon reflection.

I could package these changes up for your review and possible inclusion into Ofbiz if you feel there is value in doing so ... thoughts?

PS.  I think some of my list of changes here have been covered off by your changes.  I looked into the expression stuff in trunk, but the rest I was just eye balling in FishEye against our svn.

[Adrian Crum]

One of the things to keep in mind during these discussions is the
forthcoming ExecutionContext - a part of the security redesign. Instead
of passing a delegator around the framework, the current delegator is
assigned to the current thread and a static method exists to retrieve it
at any point in the execution path.

I should have that code committed sometime late this week, or this
weekend at the latest. Even though the new security design is disabled,
the ExecutionContext can still be used. In fact, we can use it to start
fixing issues like the ones described here.

-Adrian

Bob Morley wrote:

>
> Bob Morley wrote:
>> Will do. I seem to recall that I had to change a number of signatures  
>> in the entity pkg to float down appropriate context so default would  
>> not be used. I will dig up my work on Monday and compare to latest  
>> ofbiz trunk.
>>
>
> Adam -- I took a look at the changes that I had put in place and one of the
> fundamental problems can be seen in EntityExpr -> makeWhereString around
> line 130 "this.checkRhsType(modelEntity, null);".  The second argument there
> is meant to be the delegator.  In checkRhsType it has logic to check for a
> null delegator and if so "we'll cheat a little here and assume the default
> delegator".  Our issue was that our default delegator database looked quite
> a bit different from our "tenant" database so we would get into this code
> and use the wrong delegator and as a result the wrong entity model.
>
> We made a few changes such as ...
>
> - change the signature chain for entity expressions to provide the delegator
> - if checkRhsType is called with a null delegator we log a warning message *
> - removed default constructor for GenericValue to one that required a
> delegator
> - throw illegal argument exception if GenericDelegator is constructed with a
> null delegatorName
> - creation of GenericValue and GenericPK to require a delegator rather than
> an anti-pattern of construction and setDelegator pattern.
>
> * I wonder if this should have been changed to an IllegalArgumentException
> upon reflection.
>
> I could package these changes up for your review and possible inclusion into
> Ofbiz if you feel there is value in doing so ... thoughts?
>
> PS.  I think some of my list of changes here have been covered off by your
> changes.  I looked into the expression stuff in trunk, but the rest I was
> just eye balling in FishEye against our svn.

[Adam Heath-2]

Adrian Crum wrote:

> One of the things to keep in mind during these discussions is the
> forthcoming ExecutionContext - a part of the security redesign. Instead
> of passing a delegator around the framework, the current delegator is
> assigned to the current thread and a static method exists to retrieve it
> at any point in the execution path.
>
> I should have that code committed sometime late this week, or this
> weekend at the latest. Even though the new security design is disabled,
> the ExecutionContext can still be used. In fact, we can use it to start
> fixing issues like the ones described here.

Global statics, even per-thread, can be very bad.

Consider something stored into the cache, then referenced from another
thread.  What is the correct delegator?

Does your branch remove all delegator instance variables and method
parameters?

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>> One of the things to keep in mind during these discussions is the
>> forthcoming ExecutionContext - a part of the security redesign. Instead
>> of passing a delegator around the framework, the current delegator is
>> assigned to the current thread and a static method exists to retrieve it
>> at any point in the execution path.
>>
>> I should have that code committed sometime late this week, or this
>> weekend at the latest. Even though the new security design is disabled,
>> the ExecutionContext can still be used. In fact, we can use it to start
>> fixing issues like the ones described here.
>
> Global statics, even per-thread, can be very bad.

You are welcome to look at the branch and make any corrections you feel
are necessary.

> Consider something stored into the cache, then referenced from another
> thread.  What is the correct delegator?

Huh?

>
> Does your branch remove all delegator instance variables and method
> parameters?

No, I left that for us to work on as a community. I only have so many
hands and hours in a day. ;-)

[Adam Heath-2]

Adrian Crum wrote:
>> Consider something stored into the cache, then referenced from another
>> thread.  What is the correct delegator?
>
> Huh?

Entity caches store EntityCondition as key, and List<GenericValue> as
the value.  Fetching from the cache can still be made to work, because
the in-memory evaulation will use the thread's delegator, and
everything will work correctly.

However, when looking at the items in webtools' cache pages, you'll
end up seeing string versions of the conditions.   If the condition
objects start fetching the thread's delegator, they will end up using
the delegator that webtools has been configured to use, *not* the
version that represents the cache for which they were stored.

[Bob Morley]

On Apr 5, 2010, at 2:11 PM, Adrian Crum wrote:

> Adam Heath wrote:
>> Adrian Crum wrote:
>>> One of the things to keep in mind during these discussions is the
>>> forthcoming ExecutionContext - a part of the security redesign.  
>>> Instead
>>> of passing a delegator around the framework, the current delegator  
>>> is
>>> assigned to the current thread and a static method exists to  
>>> retrieve it
>>> at any point in the execution path.
>>>
>>> I should have that code committed sometime late this week, or this
>>> weekend at the latest. Even though the new security design is  
>>> disabled,
>>> the ExecutionContext can still be used. In fact, we can use it to  
>>> start
>>> fixing issues like the ones described here.
>> Global statics, even per-thread, can be very bad.
>
> You are welcome to look at the branch and make any corrections you  
> feel are necessary.
>
>> Consider something stored into the cache, then referenced from  
>> another
>> thread.  What is the correct delegator?
>
> Huh?

I would assume that the GenericEntity would still have an instance  
variable for its delegatorName and use that when it comes out of the  
cache.  The thread delegator would only be used for construction?

>
>> Does your branch remove all delegator instance variables and method
>> parameters?
>
> No, I left that for us to work on as a community. I only have so  
> many hands and hours in a day. ;-)
>

I will hold off on packaging up any changes until this work is in ...

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>>> Consider something stored into the cache, then referenced from another
>>> thread.  What is the correct delegator?
>> Huh?
>
> Entity caches store EntityCondition as key, and List<GenericValue> as
> the value.  Fetching from the cache can still be made to work, because
> the in-memory evaulation will use the thread's delegator, and
> everything will work correctly.
>
> However, when looking at the items in webtools' cache pages, you'll
> end up seeing string versions of the conditions.   If the condition
> objects start fetching the thread's delegator, they will end up using
> the delegator that webtools has been configured to use, *not* the
> version that represents the cache for which they were stored.

I'm sure there will be many decisions like that along the way. For now,
the basic concept is you have a user or process who is logged into a
particular delegator, and there is a static method available to retrieve
it. In most cases, that approach will simplify code. There will be
exceptions where you want to specify something different.

Let's say you have class methods that take a delegator argument. If a
delegator argument isn't null, then the assumption is to use that as an
alternate to the one the user is currently logged into (the default). If
it's null, use the default.

-Adrian