Events before saving, deleting and Updating about arangoclient.net HOT 7 OPEN

absolutely it is a good idea @jjchiw, i have thought about events and also events that raise by
database changes(when ArangoDB triggers are ready).

about the client side changes we have Update UpdateById Save SaveEdge Replace ReplaceById Remove RemoveById that can fire change events.

i will create ArangoDB.Client.Changes namespace and put fire events in there. i think the final usage would be

// client changes
db.Changes.BeforeSave
db.Changes.BeforeUpdate
db.Changes.BeforeReplace
db.Changes.BeforeRemove

// for database triggers
db.Changes.OnDatabaseUpdate
...

if you need this sooner i can add a prototype version

from arangoclient.net.

Great!

No don't worry I will wait for when you have the feature ready, right now I'm doing ok with my fork, when you have the feature the way you want it I'll merge it and everybody happy :)

from arangoclient.net.

ok @jjchiw, when i came up with the implantation, i will show the usage in this issue before move it to stable branch.

thanks again for the proposal

from arangoclient.net.

@jjchiw like you said events can be used to manipulate documents before inserting and .., my question is that are events a good choice for this? compare it with nhibernate events where it can be done by impelemnt an interface or inherit from a base class

from arangoclient.net.

It looks great, but I think it's more troublesome to add interceptors/aspects as is now the code, we should create something like a pipeline.

The events that I implemented are more simple you can add all the events that you would like to execute, the events that were added in the order that you created https://github.com/jjchiw/arangoclient.net/blob/mono-version-fireevents/ArangoDB.Client/ArangoCollection.cs#L85

I used events because I saw it in Biggy now discontinued https://github.com/xivSolutions/biggy/blob/master/src/Biggy.Core/BiggyList.cs

How would you like to implement the interceptors?

from arangoclient.net.

@jjchiw i agree using separate class is troublesome and i am fan of simplicity, if we do it by c# events we have:

    public class DocumentUpdateEventArgs : EventArgs
    {
        // object that is send from `db.Update`, user can compare this to OriginalDocument
        // and manipulate it
        public object Entity { get; set; }

        // original loaded jobject from server, we have this because of change-tracking
        public JObject OriginalDocument { get; set; }

        // Id of document, look that type of Entity can be without `id` property
        // but we can provide it for user from OriginalDocument
        public string Id { get; internal set; }

        // same as Id for Rev,Key,From,To
        public string Rev { get; internal set; }
        public string Key { get; internal set; }
        public string From { get; internal set; }
        public string To { get; internal set; }
    }

     // register an event
     // events will live in `DatabaseSharedSetting`, so all `ArangoDatabase` objects can use it
     sharedSettings.Events.BeforeUpdateDocument += (object sender, DocumentUpdateEventArgs e) =>
            {
                var product = e.Entity as Product;

                if (product !=null && e.OriginalDocument.Value<int>("Count") != product.Count)
                    product.UpdateDate = DateTime.Now;
            };

but if we do it by listeners

        public class UpdateListener : IUpdateEventListener
        {
            public bool BeforeUpdate(object entity, JObject originalDocument,
                out bool keepNull, string id, string key,string From,string To)
            {
                var product = entity as Product;

                if (product != null && originalDocument.Value<int>("Count") != product.Count)
                    product.UpdateDate = DateTime.Now;

                // handle property renames
                if(product != null)
                {
                     product.fullname = product.name + product.familyName;
                     product.name = null;
                     product.familyName = null;
                     // keep-null is arangodb server feature, not the client
                     keepNull = false;
                }

                // decide whether update document or not
                return true;
            }
        }

        // register it
        sharedSettings.UpdateListeners.Add(new UpdateListener());

one little difference is that listener can return something (for example define a rule to decide whether a change on a specific property can be made or not )
or setting variables like keepNull (which i used it in listener example) which can't be done in c# events(not until you define them in separate class [call-by-value/call-by-reference problem])

and correct me if i'm wrong, but events seems to be used for observing/auditing not manipulating the state

finally interceptors are different from events or listeners, they derived from a base class with all events that could be happen, you override the ones you need, https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/EmptyInterceptor.cs

from arangoclient.net.

I think I like more the listeners approach, It feels more "natural". About the events I'm not really sure about not manipulating the states, if you observe/audit something I think it's to do something like manipulate the state.

Anyway, I really like the part of returning something (bool) from the listener and decide to execute the action or not.

Do you have a branch where you've started this approach? because we can chain the listener if one fail the "update" does not execute or we can Aggregate the listeners......and the listeners get the value of the last listener and the last listener returns true/false.....

I don't think the listeners should be general It could be over a Collection, and when arangoclientdb starts build a map of collection with listeners. that would "fire" when the collection/document is modified....

I'm saying a lot of random stuff.... :)

from arangoclient.net.