[asterisk-dev] [Code Review]: Sorcery Data Access Abstraction Layer

[jcolp]

> On Jan. 10, 2013, 3:09 p.m., David Lee wrote:
> > /trunk/include/asterisk/sorcery.h, line 4
> > <https://reviewboard.asterisk.org/r/2259/diff/5/?file=32749#file32749line4>
> >
> >     Happy new year!

No.


> On Jan. 10, 2013, 3:09 p.m., David Lee wrote:
> > /trunk/include/asterisk/sorcery.h, line 286
> > <https://reviewboard.asterisk.org/r/2259/diff/5/?file=32749#file32749line286>
> >
> >     Interesting choice to have wizards defined per-object-type. Why not per-sorcery.

There is generally specific information that is required per-type. Table, configuration file, what have you. That can't be expressed on a global sorcery scope.


> On Jan. 10, 2013, 3:09 p.m., David Lee wrote:
> > /trunk/include/asterisk/sorcery.h, line 458
> > <https://reviewboard.asterisk.org/r/2259/diff/5/?file=32749#file32749line458>
> >
> >     Create, save or persist? It's not clear what this function is doing.

I'll tweak documentation/wording some.


> On Jan. 10, 2013, 3:09 p.m., David Lee wrote:
> > /trunk/include/asterisk/sorcery.h, line 56
> > <https://reviewboard.asterisk.org/r/2259/diff/5/?file=32749#file32749line56>
> >
> >     Why the split between the create and alloc calls?

To reduce calls into the wizard and to reduce the amount of work done, effectively. Combining create and alloc results in doing the following:

1. Creating a default object
2. Storing the default object
3. Returning (potentially) a copy of the object
4. Modifying the values of the object
5. Updating the object

An alloc function is also required regardless for wizards who want to create objects dynamically (for example from a configuration file, or using results from a database).


- jcolp


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2259/#review7654
-----------------------------------------------------------


On Jan. 9, 2013, 10:29 a.m., jcolp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2259/
> -----------------------------------------------------------
> 
> (Updated Jan. 9, 2013, 10:29 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Sorcery is a new API which provides a generic data access/persistence mechanism. A user of this API defines their objects with some special sorcery specific contents. The object types themselves and the fields within the objects are then registered with sorcery. Operations can then occur to create, retrieve, update, or delete objects. There's also other aspects present such as configuration for mapping object types to different persistence mechanisms (with the current one available being in-memory). Other operations also exist which allow objects to be copied and diffed.
> 
> * I will run whitespace-cleanup on this :P red blobs will be gone.
> 
> 
> Diffs
> -----
> 
>   /trunk/tests/test_sorcery.c PRE-CREATION 
>   /trunk/res/res_sorcery_memory.c PRE-CREATION 
>   /trunk/res/res_sorcery_config.c PRE-CREATION 
>   /trunk/main/asterisk.c 378717 
>   /trunk/main/sorcery.c PRE-CREATION 
>   /trunk/configs/test_sorcery.conf.sample PRE-CREATION 
>   /trunk/include/asterisk/sorcery.h PRE-CREATION 
>   /trunk/configs/sorcery.conf.sample PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2259/diff
> 
> 
> Testing
> -------
> 
> Ran unit tests, confirmed they all passed and made changes to ensure the tests are valid.
> 
> 
> Thanks,
> 
> jcolp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130110/d7d1fdf2/attachment-0001.htm>