You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/07/11 16:40:05 UTC

[GitHub] iilyak commented on a change in pull request #1432: Support callback module data provider

iilyak commented on a change in pull request #1432: Support callback module data provider
URL: https://github.com/apache/couchdb/pull/1432#discussion_r201762723
 
 

 ##########
 File path: src/couch_epi/src/couch_epi_data.erl
 ##########
 @@ -102,12 +102,15 @@ definitions({file, FilePath}) ->
         {error, Reason} ->
             {error, {FilePath, Reason}}
     end;
-definitions({module, Module}) when is_atom(Module) ->
-    definitions({module, [Module]});
-definitions({module, Modules}) ->
+definitions({static_module, Module}) when is_atom(Module) ->
+    definitions({static_module, [Module]});
+definitions({static_module, Modules}) ->
     Data = lists:append([M:data() || M <- Modules]),
     Hash = couch_epi_functions_gen:hash(Modules),
-    {ok, Hash, Data}.
+    {ok, Hash, Data};
+definitions({callback_module, Module}) ->
+    Data = Module:data(),
 
 Review comment:
   I am not sure if there is a value in `static_module` provider. Because if your data term is hardcoded anyway why would you generate a wrapper module.
   The only useful case is if we would decide to generate a versioned record access functions. Then the `data/0` would contain calls to pseudo function `record_info`. Even in this use case we can use `callback_module` logic. 
   
   Let me know if you think we should just kill previous implementation of `module` provider. 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services