Make sense Michael,
Its good idea to not to define new datasource for new group to avoid
unnecessary complexity,
will add this group in delegator group mapping and set the default
datasource for new group.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Thu, May 11, 2017 at 11:35 PM, Michael Brohl <michael.br...@ecomify.de>
wrote:
> Mmmhh, I would propose it the other way around for the default: use the
> same data resource for the new group.
>
> Visits and such are only a problem in large production settings with lots
> of traffic. Users who will set up such an environment will have to do some
> other tweaks as well and will have no problem to configure the new group
> for the use of another data resource.
>
> Whereas new users and those who have lower traffic will not need another
> database. I would like to keep it simple here to avoid confusion and
> unnecessary complexity.
>
> Best regards,
>
> Michael
>
>
> Am 11.05.17 um 18:34 schrieb Deepak Dixit:
>
> Yes Michael, you understood correctly
>>
>> 3) added a new entity group ("org.ofbiz.stats") for the
>>>>>
>>>> Visit/Visitor/ServerHit* (and related) entities; for now the group is
>> not
>> active so that the entities are still in the same database as before;
>> however assigning them to a different database is now a matter of
>> uncommenting the group file definition in framework/webapp/ofbiz-compone
>> nt.xml
>> and provide the new datasource definition
>>
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <michael.br...@ecomify.de>
>> wrote:
>>
>> Hi Deepak,
>>>
>>> I'm not sure if I understand correctly. Do you propose to configure
>>> different databases/data resources for the Visits* entity group?
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>>>
>>> I think we can enable the commented group and can add this in
>>>
>>>> entityengine.xml.
>>>> Definitely it will increase one database creation, but if user doesn't
>>>> want
>>>> to create new database user can use same data-resource used for
>>>> org.apache.ofbiz package.
>>>>
>>>> Others opinion ?
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>>
>>>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>>>> jacopo.cappell...@hotwaxmedia.com> wrote:
>>>>
>>>> Thanks to all of you for your valuable feedback.
>>>>
>>>>> The first pass of this work is now complete, please refer to rev.
>>>>> 1647271
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>>>> hotwaxmedia.com> wrote:
>>>>>
>>>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>>> are used to gather statistics about how clients use the OFBiz instance.
>>>>>
>>>>> The information in these entities is not used by business processes but
>>>>>>
>>>>>> it is very important to analyze the system performance, user's
>>>>> behavior
>>>>> etc...
>>>>>
>>>>> This simple data model is very powerful because can capture very
>>>>>>
>>>>>> granular information about each visit.
>>>>>
>>>>> The disadvantage is that it can add significant load on the database
>>>>>>
>>>>>> server and can impact performance; on servers with high users load
>>>>> these
>>>>> tables can be huge; in fact, in most production instances the granular
>>>>> logging is disabled.
>>>>>
>>>>> I am proposing here a change that should make the stat gathering
>>>>>>
>>>>>> subcomponent more flexible, clean and powerful, and increase the
>>>>> performance of the system:
>>>>>
>>>>> 1) remove all the fk dependencies from business entities to the
>>>>>>
>>>>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>>>
>>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>>>
>>>>>> *Type entities) entities to a separate entity-group
>>>>>
>>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>>>
>>>>>> them in a separate database (e.g. a NoSQL db); by default we could
>>>>> keep
>>>>> them in the same db where all the other entities are
>>>>>
>>>>> What do you think?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>
>>>
>
>
