Stef,
A pluggable solution makes a lot of sense ... I understand your concerns: you don't want Moose to be locked into a GemStone-only solution (for example). Maintaining flexibility here would be one of the considerations in working toward a solution...
Dale ----- Original Message -----
| From: "Stéphane Ducasse" stephane.ducasse@inria.fr | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Tuesday, August 20, 2013 10:36:36 AM | Subject: [Moose-dev] Re: persisting moose models
| On Aug 20, 2013, at 12:02 PM, Tudor Girba < tudor@tudorgirba.com > | wrote:
| | Hi Fabrizio, |
| | How large is the MSE file? |
| | I understand your concern, but I do not think that a relational | | database would work well in this case. Probably much better would | | be | | a MongoDB. But, at the same time, it would be cool to try using a | | Gemstone and have FAMIX be compatible with it (that should not be | | hard). | | what is important is that this behavior should be pluggable because | when we deploy an application based on Moose. We do not want to have | to install | any database and if we would we need to control the licensing and any | other legal aspects.
| | Cheers, | | | Doru |
| | On Tue, Aug 20, 2013 at 11:31 AM, Fabrizio Perin < | | fabrizio.perin@gmail.com > wrote: |
| | | Performace is always glad to have but if you cannot do your | | | analyses | | | in the first place because you run out of memory, than it became | | | not | | | a problem. I don't think FUEL is an option in my case, in the | | | sense | | | that with a DB you can fetch a bunch of rows at the time and so | | | you | | | can have your data while keeping the memory cosumption | | | manageable. | | | With FUEL I will need to deserialize all and than do the search. | | | FUEL could help to set up a filesystem DB and so the DBMS can use | | | FUEL to quickly serialize and deserialize objects. On that | | | matter, | | | I | | | would rather prefer to use an existing persistent framework and | | | not | | | to build one from scratch. | | |
| | | thanks, | | | | | | Fabrizio | | |
| | | 2013/8/20 Diego Lont < diego.lont@delware.nl > | | |
| | | | Hi Fabrizio, | | | | | |
| | | | The focus of a database is persistency, not performance of | | | | large | | | | datasets, so this will probably not help you. | | | | | |
| | | | So I would suggest the following directions for a solution: | | | | | | | | | | Use a more memory efficient model than FAMIX (or improve the | | | | memory | | | | consumption of this model) | | | | | | | | | | Export chuncks of data using FUEL | | | | | | | | | | Link several Moose images that share memory | | | | | | | | | | or Link a Moose image to a gemstone to store the data and do | | | | the | | | | processing. | | | | | |
| | | | Regards, | | | | | | | | | | Diego | | | | | |
| | | | On Aug 20, 2013, at 10:51 AM, Fabrizio Perin wrote: | | | | | |
| | | | | Hi Stef, | | | | | | | | | | | | | | | How to store the elements on the DB I think will depend on | | | | | which | | | | | DBMS | | | | | you use. With a, e.g., a ORDBMS, we can replicate exactly the | | | | | structure of the MooseModel within the DB. In my mind I will | | | | | have | | | | | a | | | | | MoosePersistentModel object which hold a reference to the | | | | | MooseModel | | | | | stored into the DB and that translate all the operations you | | | | | can | | | | | do | | | | | to search, add, remove and modify an entity in executable SQL | | | | | and | | | | | send it to the DB. It sounds really ambitious, but I think I | | | | | will | | | | | realize soon after I will start the development if this idea | | | | | can | | | | | work or not. | | | | | | | | | |
| | | | | Now I just need to identify which DBMS to use and I should | | | | | decide | | | | | which persistent framework in Pharo to use. I was thinking at | | | | | Glorp | | | | | (with a Postgres DB behind) or at Magma, although I never | | | | | used | | | | | neither of them. do you think that they would be suitale for | | | | | my | | | | | purpose? Do you have any other candidate to propose? Do you | | | | | know | | | | | if | | | | | there is some nice "getting start documentation" for Magma | | | | | and | | | | | Glorp? | | | | | | | | | |
| | | | | Thanks a lot, | | | | | | | | | | | | | | | Fabrizio | | | | | | | | | |
| | | | | 2013/8/19 Stéphane Ducasse < stephane.ducasse@inria.fr > | | | | | | | | | |
| | | | | | HI fabrizio | | | | | | | | | | | | | | |
| | | | | | may be you should ask in the pharo mailing-list. | | | | | | | | | | | | | | | | | | | | | Now the problem to me is how to persist a graph of | | | | | | pointers. | | | | | | | | | | | | | | |
| | | | | | In early version of Moose long time ago there were no | | | | | | pointers | | | | | | to | | | | | | methods, class….but id | | | | | | | | | | | | | | | | | | | | | So all the code was full of | | | | | | | | | | | | | | |
| | | | | | FAMIXMethod>>msClass | | | | | | | | | | | | | | | | | | | | | Model entityWithId: self msClassId | | | | | | | | | | | | | | |
| | | | | | and you could easily plug a stupid DB behind. | | | | | | | | | | | | | | | | | | | | | Then we decided to use pointers. | | | | | | | | | | | | | | |
| | | | | | But now to me this is not clear how we can save/load part | | | | | | of | | | | | | a | | | | | | large | | | | | | graph. | | | | | | | | | | | | | | |
| | | | | | stef | | | | | | | | | | | | | | |
| | | | | | > Hi, | | | | | | | | | | | | | | | | | | | | | > I will soon need to analyze quite some java code at once | | | | | | > and | | | | | | > I'm | | | | | | > already sure that one Moose image will not be enough for | | | | | | > all | | | | | | > that | | | | | | > code. Therefore I would like to try to persist the model | | | | | | > on | | | | | | > a | | | | | | > database. Do you have any pointer to a possible | | | | | | > persistence | | | | | | > manager/OODBMS/RODBMS to use for that purpose? | | | | | | | | | | | | | | | | | | | | | > | | | | | | | | | | | | | | | | | | | | | > Thanks in advance, | | | | | | | | | | | | | | | | | | | | | > Fabrizio | | | | | | | | | | | | | | | | | | | | | > _______________________________________________ | | | | | | | | | | | | | | | | | | | | | > Moose-dev mailing list | | | | | | | | | | | | | | | | | | | | | > Moose-dev@iam.unibe.ch | | | | | | | | | | | | | | | | | | | | | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | | | | | | | | | | | |
| | | | | | _______________________________________________ | | | | | | | | | | | | | | | | | | | | | Moose-dev mailing list | | | | | | | | | | | | | | | | | | | | | Moose-dev@iam.unibe.ch | | | | | | | | | | | | | | | | | | | | | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | | | | | | | | | | | |
| | | | | _______________________________________________ | | | | | | | | | | | | | | | Moose-dev mailing list | | | | | | | | | | | | | | | Moose-dev@iam.unibe.ch | | | | | | | | | | | | | | | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | | | | | | |
| | | | _______________________________________________ | | | | | | | | | | Moose-dev mailing list | | | | | | | | | | Moose-dev@iam.unibe.ch | | | | | | | | | | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | | |
| | | _______________________________________________ | | | | | | Moose-dev mailing list | | | | | | Moose-dev@iam.unibe.ch | | | | | | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | |
| | -- |
| | www.tudorgirba.com |
| | "Every thing has its own flow" | | _______________________________________________ | | | Moose-dev mailing list | | | Moose-dev@iam.unibe.ch | | | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
| _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev