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
