ah very nice client you had :) Thank you Mariano very much will take a deep look into it and I am sure will be back with more questions, its fascinating.
On Mon, Nov 30, 2015 at 7:54 PM Mariano Martinez Peck <marianop...@gmail.com> wrote: > On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > >> ah this is very good news for me thanks. I really like Fuel, well done >> guys, looks very well designed. >> >> Yeah feature wise I dont care about something advanced, If I need >> something much more advanced I will use a proper database. >> >> I am slightly surprised that none or at least AFAIK has not create a >> lightweight database API based on Fuel . Something similar to SQLite. >> >> https://www.sqlite.org/ >> >> > Well, we did and my client agree to open source it: > http://smalltalkhub.com/#!/~Debris/DebrisDB > So...you could either try that or SimplePersistentcy. > > About scale, I guess I can brake things to multiple files. >> > > That's what we do in our application. Not necessary as for performance but > also as for domain logic. We have advisorDB, clientsDB, securitiesDB, etc, > which are all logic app-dependent databases. And then all these logic > databases are stored (somehow) into real databases. > > >> On other thread someone mention that STON is a good choice for version >> control but that is not a problem for me either since Git can handle binary >> files like fuel files too. >> >> On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck < >> marianop...@gmail.com> wrote: >> >>> On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis < >>> kilon.al...@gmail.com> wrote: >>> >>>> Yes I have read the docs on how to use Fuel on how to use it and how to >>>> exclude things I dont want to be stored in fuel file, I was just curious. >>>> As a matter of fact I like deep copies. >>>> >>>> Is it ok to use Fuel to make my own , super light, database ? Just a >>>> way to manage and port my objects between images. Nothing very >>>> sophisticated. >>>> >>> >>> Yes, we did this for Quuve application when it runs (for development) >>> under Pharo. Of course, it will only work up to certain scale (since every >>> commit will serialize the whole database) and you do not have ACID, nor DB >>> users, no security, nor any other features of a real DB. >>> >>> You may want to take a look to simple persistence to save some of your >>> development time since it has a Fuel backend: >>> http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence >>> >>> >>>> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck < >>>> marianop...@gmail.com> wrote: >>>> >>>>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < >>>>> kilon.al...@gmail.com> wrote: >>>>> >>>>>> I have a class A that has an instance variable the references an >>>>>> instance of Class B , but also Class B has an instance variable the >>>>>> references an instance of Class A. Basically its a GUI that references >>>>>> its >>>>>> model and the same model referencing the same instance of GUI. >>>>>> >>>>>> >>>>> Dimitris, >>>>> >>>>> Fuel solves the circular references in the traditional way, that is, >>>>> while traversing the graph, after processing each objects it stores it in >>>>> a >>>>> IdentityDictionary. Then, for each object to be processed, it first checks >>>>> if the dictionary already includes that object. If true, then it has >>>>> already been processed. If not, then lets process/traverse. >>>>> >>>>> >>>>> >>>>>> How Fuel deals with such scenario because I saw that it created an >>>>>> output of 1.5 mbs for several instances of my model class ? Is there any >>>>>> danger of having such circular references or it does not matter because >>>>>> afterall they are just pointers ? >>>>>> >>>>> >>>>> As Sven said, you need to be careful because you cannot be sure >>>>> exactly all what Fuel can reach from a certain graph. If the graph was >>>>> serialized into a 1.5mb then it has nothing to do to the fact of having >>>>> circular references. It's simply the fact of the graph that ended up >>>>> traversed. >>>>> >>>>> There are some tools inside Fuel to know what has been >>>>> "traversed/processed" and that will next be serialized. This may help you >>>>> realize that you are including in the graph things you don't want. We have >>>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging >>>>> but I am not sure if that's a bit outdated. Give it a try and if not ask. >>>>> The ideally is to at least get the list of classes and instances that are >>>>> being serialized. That's quite a help in a first place. >>>>> >>>>> Finally, if you found parts of the graph that you didn't want to >>>>> serialize, then you can use different Fuel hooks to solve that >>>>> (substitutions, ignoring certain intsVars, etc etc). >>>>> >>>>> Best, >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
