How fuel deals with circular reference ?
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. 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 ?
Both Fuel and STON deal correctly with circular references and structure sharing. However, and this is an important difference, since FUEL is saving everything it sees (everything your objects point to), it often saves a lot (way more than you expect). STON (and JSON, XML, ..) are much less powerful, they require you to carefully think about and design the domain model objects that you want to serialise/persistent (i.e. make sure they don't point to system stuff, or at least skip these). The result will be much cleaner and smaller output.
On 30 Nov 2015, at 12:41, Dimitris Chloupis <kilon.alios@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.
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 ?
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <kilon.alios@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
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. On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <kilon.alios@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
On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <kilon.alios@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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <kilon.alios@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
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/ About scale, I guess I can brake things to multiple files. 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 <marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <kilon.alios@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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < kilon.alios@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
On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <kilon.alios@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.
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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis < kilon.alios@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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < kilon.alios@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
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 <marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <kilon.alios@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.
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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis < kilon.alios@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 < marianopeck@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < kilon.alios@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
Hi, On 30/11/15 12:42, Dimitris Chloupis 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.
If you like sqlite, you should take a look to: [1] and [2] [1] http://fossil-scm.org/ [2] http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki
About scale, I guess I can brake things to multiple files. 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.
I made it. But I was not referring to the fact of store binaries in a DVCS (most of them can do it) but about diff-ing the STON file in a human and DVCS friendly way. Cheers, Offray
participants (4)
-
Dimitris Chloupis -
Mariano Martinez Peck -
Offray Vladimir Luna Cárdenas -
Sven Van Caekenberghe