How fuel deals with circular reference ?

On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <[hidden email]> 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

On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <[hidden email]> 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

On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <[hidden email]> 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