You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2014/12/18 09:47:31 UTC
Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit*
entities
Posted by Jacques Le Roux <ja...@les7arts.com>.
Since those statistics entities have no functional impacts on business entities, that sounds pretty reasonable to me.
Just a question, did you already try (free?) JDBC drivers for NoSQL DBs, like Apache Cassandra or MongoDB for instance?
Jacques
Le 18/12/2014 09:47, Jacopo Cappellato a écrit :
> 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
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Pranay Pandey <pr...@hotwaxmedia.com>.
+1
It will be really great enhancement. Disabling logging to these entities
because of increased load shouldn't be a choice for sure.
Thanks,
Pranay Pandey
HotWax Media
www.hotwaxmedia.com
On Thu, Dec 18, 2014 at 2:17 PM, 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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Arun Patidar <ar...@hotwaxmedia.com>.
+1
Thanks & Regards
---
Arun Patidar
Manager,Enterprise Software Development
HotWax Media
www.hotwaxmedia.com
On Thursday 18 December 2014 03:20 PM, Ashish Vijaywargiya wrote:
> Very Good Idea, +1 for this change.
>
> --
> Kind Regards,
> Ashish Vijaywargiya
>
>
> On Thu, Dec 18, 2014 at 2:17 PM, 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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Ashish Vijaywargiya <vi...@gmail.com>.
Very Good Idea, +1 for this change.
--
Kind Regards,
Ashish Vijaywargiya
On Thu, Dec 18, 2014 at 2:17 PM, 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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Adrian Crum <ad...@sandglass-software.com>.
+1
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 12/18/2014 8:47 AM, Jacopo Cappellato 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
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by gil portenseigne <gi...@nereide.fr>.
Seems to be a good enhancement, not changing default behaviour, so +1 !
Gil
Le 18/12/2014 09:47, Jacopo Cappellato a écrit :
> 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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Anahita Goljahani <an...@gmail.com>.
+1
I agree with others that it is a very useful enhancement!
Kind regards
Anahita
2014-12-19 11:06 GMT+01:00 Deepak Dixit <de...@hotwaxmedia.com>:
>
> +1
>
> Thanks & Regards
> —
> Deepak Dixit
>
>
> > On Dec 18, 2014, at 2:17 PM, 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
>
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Deepak Dixit <de...@hotwaxmedia.com>.
+1
Thanks & Regards
—
Deepak Dixit
> On Dec 18, 2014, at 2:17 PM, Jacopo Cappellato <ja...@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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Anil K Patel <an...@hotwaxmedia.com>.
+1
Ability to store data in NoSQL database is super important.
Thanks and Regards
Anil Patel
COO
Hotwax Media Inc
http://www.hotwaxmedia.com/
ApacheCon US 2014 Silver Sponsor
http://na.apachecon.com/sponsor/our-sponsors
> On Dec 18, 2014, at 3:47 AM, Jacopo Cappellato <ja...@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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Divesh Dutta <di...@hotwaxmedia.com>.
This will really be a good improvement in OFBiz. Sounds like good plan to
me.
Thanks
--
Divesh
On Thu, Dec 18, 2014 at 2:17 PM, 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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Thu, May 11, 2017 at 8:38 PM, Deepak Dixit <
deepak.dixit@hotwaxsystems.com> wrote:
> 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.
>
>
If I am not wrong, mapping the two groups to the same datasource may
trigger a series of warnings at startup (for missing entities): if that is
the case, and we do not like the idea of having two separate datasources as
a default, then we may keep the current setup (i.e. with the group
commented out).
Jacopo
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit*
entities
Posted by Michael Brohl <mi...@ecomify.de>.
Thanks Deepak!
Am 11.05.17 um 20:54 schrieb Deepak Dixit:
> Here is the ticket for enabling stats group
> https://issues.apache.org/jira/browse/OFBIZ-9356
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Fri, May 12, 2017 at 12:08 AM, Deepak Dixit <
> deepak.dixit@hotwaxsystems.com> wrote:
>
>> 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 <mi...@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.brohl@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.cappellato@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
>>>>>>>>
>>>>>>>>
>>>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
Here is the ticket for enabling stats group
https://issues.apache.org/jira/browse/OFBIZ-9356
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Fri, May 12, 2017 at 12:08 AM, Deepak Dixit <
deepak.dixit@hotwaxsystems.com> wrote:
> 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 <mi...@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.brohl@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.cappellato@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>>
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
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 <mi...@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 <mi...@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.cappellato@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
>>>>>>
>>>>>>
>>>>>
>>>
>
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit*
entities
Posted by Michael Brohl <mi...@ecomify.de>.
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-component.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 <mi...@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.cappellato@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
>>>>>
>>>>
>>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
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-component.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 <mi...@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.cappellato@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
>>>>
>>>
>>>
>
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit*
entities
Posted by Michael Brohl <mi...@ecomify.de>.
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.cappellato@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
>>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
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.cappellato@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
>
>
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 <ja...@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
Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities
Posted by Mridul Pathak <mr...@hotwaxmedia.com>.
+1, Very useful enhancement.
--
Regards,
Mridul Pathak
> On Dec 18, 2014, at 2:17 PM, Jacopo Cappellato <ja...@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