mirror of
https://github.com/yweber/lodel2.git
synced 2025-10-30 02:59:03 +01:00
Documentation cleaning on the lodel.plugins.mongodb_datasource package
This commit is contained in:
parent
5f42e19292
commit
46479ab170
1 changed files with 33 additions and 31 deletions
|
|
@ -13,52 +13,54 @@ __fullname__ = "MongoDB plugin"
|
|||
|
||||
## @brief Activates the plugin
|
||||
#
|
||||
# @note It is possible there to add some specific actions (like checks, etc ...) for the plugin
|
||||
# @note This function can contain specific actions (like checks, etc ...) in
|
||||
# order to activate the plugin.
|
||||
#
|
||||
# @return bool|str : True if all the checks are OK, an error message if not
|
||||
def _activate():
|
||||
from lodel import buildconf #NOTE : this one do not have to pass through the context
|
||||
from lodel import buildconf # NOTE : this one do not have to pass through the context
|
||||
return buildconf.PYMONGO
|
||||
|
||||
#
|
||||
# Doxygen comments
|
||||
#
|
||||
|
||||
##@defgroup plugin_mongodb_datasource MongoDB datasource plugin
|
||||
#@brief Doc about mongodb datasource
|
||||
## @defgroup plugin_mongodb_datasource MongoDB datasource plugin
|
||||
# @brief Doc about mongodb datasource
|
||||
|
||||
##@page plugin_mongodb_backref_complexity Reflexion on back reference complexity
|
||||
#@ingroup plugin_mongodb_bref_op
|
||||
## @page plugin_mongodb_backref_complexity Reflexion on back reference complexity
|
||||
# @ingroup plugin_mongodb_bref_op
|
||||
#
|
||||
#Their is a huge performance issue in the way we implemented references
|
||||
#and back references for mongodb datasource :
|
||||
# There is a huge performance issue in the way we implemented references and
|
||||
# back references for mongodb datasource :
|
||||
#
|
||||
#For each write action (update, delete or insert) we HAVE TO run a select
|
||||
#on all concerned LeObject. In fact those methods headers looks like
|
||||
#<pre>def write_action(target_cls, filters, [datas])</pre>
|
||||
# For each write action (update, delete or insert) we HAVE TO run a select
|
||||
# on all concerned LeObject instances. Those methods' headers look like
|
||||
# <pre>def write_action(target_cls, filters, [datas])</pre>.
|
||||
#
|
||||
#We have no idea if all the modified objects are of the target class (they
|
||||
#can be of any target's child classes). So that means we have no idea of the
|
||||
#@ref base_classes.Reference "References" that will be modified by the action.
|
||||
# We have no idea if all the modified objects are of the target class (they
|
||||
# can be of any target's child classes). So that means we have no idea of the
|
||||
# @ref base_classes.Reference "References" that will be modified by the action.
|
||||
#
|
||||
#Another problem is that when we run an update or a delete we have no idea
|
||||
#of the values that will be updated or deleted (we do not have the concerned
|
||||
#instances datas). As a result we cannot replace or delete the concerned
|
||||
#back references.
|
||||
# Another problem is that when we run an update or a delete we have no idea
|
||||
# of the values that will be updated or deleted (we do not have the concerned
|
||||
# instances datas). As a result we cannot replace or delete the concerned
|
||||
# back references.
|
||||
#
|
||||
#In term of complexity the number of DB query looks like :
|
||||
#<pre>
|
||||
#With n the number of instances to modify :
|
||||
#queryO(n) ~= 2n ( n * select + n * update )
|
||||
#</pre>
|
||||
#But it can go really bad, really fast if we take in consideration that
|
||||
#query's can be done on mixed classes or abstract classes. With :
|
||||
#- n : the number of LeObect child classes represented by the abstract class
|
||||
#- m : the number of LeObject child classes for each n
|
||||
#- o : the number of concerned back_reference classes for each m
|
||||
# In term of complexity the number of DB query looks like :
|
||||
# <pre>
|
||||
# With n the number of instances to modify :
|
||||
# queryO(n) ~= 2n ( n * select + n * update )
|
||||
# </pre>
|
||||
#
|
||||
#<pre>queryO(n,m,o) ~= n + (n*m) + (n*m*o) => n + n*m select and n*m*o updates</pre>
|
||||
# But it can go really bad, really fast if we take in consideration that
|
||||
# query's can be done on mixed classes or abstract classes. With :
|
||||
# - n : the number of LeObect child classes represented by the abstract class
|
||||
# - m : the number of LeObject child classes for each n
|
||||
# - o : the number of concerned back_reference classes for each m
|
||||
#
|
||||
#All of this is really sad especially as the update and the delete will be
|
||||
#run on LeObject instances....
|
||||
# <pre>queryO(n,m,o) ~= n + (n*m) + (n*m*o) => n + n*m select and n*m*o updates</pre>
|
||||
#
|
||||
# All of this is really sad especially as the update and the delete will be
|
||||
# run on LeObject instances....
|
||||
#
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue