Browse Source

Documentation cleaning on the lodel.plugins.mongodb_datasource package

Roland Haroutiounian 7 years ago
parent
commit
46479ab170
1 changed files with 33 additions and 31 deletions
  1. 33
    31
      lodel/plugins/mongodb_datasource/__init__.py

+ 33
- 31
lodel/plugins/mongodb_datasource/__init__.py View File

13
 
13
 
14
 ## @brief Activates the plugin
14
 ## @brief Activates the plugin
15
 #
15
 #
16
-# @note It is possible there to add some specific actions (like checks, etc ...) for the plugin
16
+# @note This function can contain specific actions (like checks, etc ...) in 
17
+#  order to activate the plugin.
17
 #
18
 #
18
 # @return bool|str : True if all the checks are OK, an error message if not
19
 # @return bool|str : True if all the checks are OK, an error message if not
19
 def _activate():
20
 def _activate():
20
-    from lodel import buildconf #NOTE : this one do not have to pass through the context
21
+    from lodel import buildconf  # NOTE : this one do not have to pass through the context
21
     return buildconf.PYMONGO
22
     return buildconf.PYMONGO
22
 
23
 
23
 #
24
 #
24
 #   Doxygen comments
25
 #   Doxygen comments
25
 #
26
 #
26
 
27
 
27
-##@defgroup plugin_mongodb_datasource MongoDB datasource plugin
28
-#@brief Doc about mongodb datasource
28
+## @defgroup plugin_mongodb_datasource MongoDB datasource plugin
29
+# @brief Doc about mongodb datasource
29
 
30
 
30
-##@page plugin_mongodb_backref_complexity Reflexion on back reference complexity
31
-#@ingroup plugin_mongodb_bref_op
31
+## @page plugin_mongodb_backref_complexity Reflexion on back reference complexity
32
+# @ingroup plugin_mongodb_bref_op
32
 #
33
 #
33
-#Their is a huge performance issue in the way we implemented references
34
-#and back references for mongodb datasource :
34
+# There is a huge performance issue in the way we implemented references and 
35
+# back references for mongodb datasource :
35
 #
36
 #
36
-#For each write action (update, delete or insert) we HAVE TO run a select
37
-#on all concerned LeObject. In fact those methods headers looks like
38
-#<pre>def write_action(target_cls, filters, [datas])</pre>
37
+# For each write action (update, delete or insert) we HAVE TO run a select
38
+# on all concerned LeObject instances. Those methods' headers look like
39
+# <pre>def write_action(target_cls, filters, [datas])</pre>.
39
 #
40
 #
40
-#We have no idea if all the modified objects are of the target class (they
41
-#can be of any target's child classes). So that means we have no idea of the
42
-#@ref base_classes.Reference "References" that will be modified by the action.
41
+# We have no idea if all the modified objects are of the target class (they
42
+# can be of any target's child classes). So that means we have no idea of the
43
+# @ref base_classes.Reference "References" that will be modified by the action.
43
 #
44
 #
44
-#Another problem is that when we run an update or a delete we have no idea
45
-#of the values that will be updated or deleted (we do not have the concerned
46
-#instances datas). As a result we cannot replace or delete the concerned
47
-#back references.
45
+# Another problem is that when we run an update or a delete we have no idea
46
+# of the values that will be updated or deleted (we do not have the concerned
47
+# instances datas). As a result we cannot replace or delete the concerned
48
+# back references.
48
 #
49
 #
49
-#In term of complexity the number of DB query looks like :
50
-#<pre>
51
-#With n the number of instances to modify : 
52
-#queryO(n) ~=  2n ( n * select + n * update )
53
-#</pre>
54
-#But it can go really bad, really fast if we take in consideration that
55
-#query's can be done on mixed classes or abstract classes. With :
56
-#- n : the number of LeObect child classes represented by the abstract class
57
-#- m : the number of LeObject child classes for each n
58
-#- o : the number of concerned back_reference classes for each m
50
+# In term of complexity the number of DB query looks like :
51
+# <pre>
52
+# With n the number of instances to modify : 
53
+#   queryO(n) ~=  2n ( n * select + n * update )
54
+# </pre>
59
 #
55
 #
60
-#<pre>queryO(n,m,o) ~=  n + (n*m) + (n*m*o) => n + n*m select and n*m*o updates</pre>
56
+# But it can go really bad, really fast if we take in consideration that
57
+# query's can be done on mixed classes or abstract classes. With :
58
+# - n : the number of LeObect child classes represented by the abstract class
59
+# - m : the number of LeObject child classes for each n
60
+# - o : the number of concerned back_reference classes for each m
61
 #
61
 #
62
-#All of this is really sad especially as the update and the delete will be
63
-#run on LeObject instances....
62
+# <pre>queryO(n,m,o) ~=  n + (n*m) + (n*m*o) => n + n*m select and n*m*o updates</pre>
63
+#
64
+# All of this is really sad especially as the update and the delete will be
65
+# run on LeObject instances....
64
 #
66
 #

Loading…
Cancel
Save