- Pharo-users - lists.pharo.org

Re: [Pharo-users] Ston feature idea?

by Cyril Ferlicot D.

On 17/05/2017 16:33, Sven Van Caekenberghe wrote: > > > You change the representation of MooseEntity to the above short form, then you just use MooseEntity instances inside other objects. All other instance variables of MooseEntity will be skipped. > > Just like Date, Time, or DateAndTime have short representations, that you see when you include these as values inside other objects. > > We must be talking about something different because I really don't see the problem. > > > Now I see why I did not understood. I wanted the container to change his variables containing the moose entities. So I though that you talked about the container of the MooseEntity and not about the moose entity itself. For now I wanted to avoid modifying the ston properties of MooseEntity because we have other ston exporters that export some of them with hacks and I did not wanted to update all of them at the same time. (It risk to break some features and we try to stabilize our tools) But I think I will need to do it. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Sven Van Caekenberghe

> On 17 May 2017, at 16:27, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 17/05/2017 16:25, Sven Van Caekenberghe wrote: >> >> >> OK. >> >> So there is some existing method that gives you the entity given its name ? >> >> MooseEntity class>>fromEntityName: 'mooseEntityName' >> >> Right ? >> >> So why can't you use the example that I gave you earlier, replace the UUID string with the mooseEntityName string, and call the above method instead of the #fromId: in my example ? >> >> In STON, you will then see >> >> MooseEntity['mooseEntityName'] >> >> as value. >> > > But it would not export/import all the other variables no? You change the representation of MooseEntity to the above short form, then you just use MooseEntity instances inside other objects. All other instance variables of MooseEntity will be skipped. Just like Date, Time, or DateAndTime have short representations, that you see when you include these as values inside other objects. We must be talking about something different because I really don't see the problem. >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Cyril Ferlicot D.

On 17/05/2017 16:25, Sven Van Caekenberghe wrote: > > > OK. > > So there is some existing method that gives you the entity given its name ? > > MooseEntity class>>fromEntityName: 'mooseEntityName' > > Right ? > > So why can't you use the example that I gave you earlier, replace the UUID string with the mooseEntityName string, and call the above method instead of the #fromId: in my example ? > > In STON, you will then see > > MooseEntity['mooseEntityName'] > > as value. > But it would not export/import all the other variables no? > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Sven Van Caekenberghe

> On 17 May 2017, at 16:15, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 17/05/2017 16:02, Sven Van Caekenberghe wrote: >> >> OK, that is an understandable example. >> >> But why exactly do you want Currency to be serialised differently ? You don't want too many instances ? You want all instances to be #== ? Is Currency too big ? You want to allow humans to edit the STON file ? What ? Why ? >> >> You can easily make it Currency['Euro'] or even Currency[#Euro] like it is already done for a number of built-in classes. >> >> The last example that I gave solved the 'too many instances', make them #== issue. >> >> If it is size, that got covered too, but you must solve the problem of how the receiving end will resolve the reference then. >> >> But since that is all no good, there must still be another requirement. > > Here it is a simple example to show what I want. > > The real use case is that in Moose, entities are really connected to > their model, and if one of our classes contains an entity it would > produce a really really really big ston file since it would export > millions of entities. > > But there is a way to retrieve an entity of this model from its moose name. > > Thus, I would like to export only the moose name of the entities, then > get the corresponding entity from a Model the user would have load > before during the ston reading. OK. So there is some existing method that gives you the entity given its name ? MooseEntity class>>fromEntityName: 'mooseEntityName' Right ? So why can't you use the example that I gave you earlier, replace the UUID string with the mooseEntityName string, and call the above method instead of the #fromId: in my example ? In STON, you will then see MooseEntity['mooseEntityName'] as value. >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Cyril Ferlicot D.

On 17/05/2017 16:02, Sven Van Caekenberghe wrote: > > OK, that is an understandable example. > > But why exactly do you want Currency to be serialised differently ? You don't want too many instances ? You want all instances to be #== ? Is Currency too big ? You want to allow humans to edit the STON file ? What ? Why ? > > You can easily make it Currency['Euro'] or even Currency[#Euro] like it is already done for a number of built-in classes. > > The last example that I gave solved the 'too many instances', make them #== issue. > > If it is size, that got covered too, but you must solve the problem of how the receiving end will resolve the reference then. > > But since that is all no good, there must still be another requirement. Here it is a simple example to show what I want. The real use case is that in Moose, entities are really connected to their model, and if one of our classes contains an entity it would produce a really really really big ston file since it would export millions of entities. But there is a way to retrieve an entity of this model from its moose name. Thus, I would like to export only the moose name of the entities, then get the corresponding entity from a Model the user would have load before during the ston reading. > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 17, 2017

Re: [Pharo-users] Loading Glorp+PostgreSQL

by Sven Van Caekenberghe

> On 17 May 2017, at 16:01, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Tue, May 16, 2017 at 11:58:50AM +0200, Sven Van Caekenberghe wrote: >> I am bringing my Reddit example back up to date (https://medium.com/concerning-pharo/reddit-st-in-10-cool-pharo-classes-1b53…) for an upcoming Pharo Booklet. > > Hi Sven, > > I've adapted your Reddit application to work with Glorp-SQLite. It was pretty > much simply subclassing RedditDatabaseResource and wiring up #newGlorpSession. > It's a nice demo of Glorp's pluggability. That is cool. We should definitively keep a reference to that. Thanks. > Pierce >

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Sven Van Caekenberghe

> On 17 May 2017, at 15:47, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 17/05/2017 15:17, Sven Van Caekenberghe wrote: >> >> >> OK. >> >> But don't go too far in writing actual code. I want to understand the use case at a high level (like how you started), then I can try to find how/if STON can do what you want. Right now, you are already too deep into a possible solution. >> >> > > If I have to give a really simple use case. > > Imagine an invoice. > > The invoice has the name of the customer and the currency used as a class. > > During the export of the invoice you do not want to export the currency > as a class but as a String. > > So if I have an Invoice instance like this: > > username: 'user' > currency: Currency[Euro] > > I want to transform the currency to a string during the export. (and > keep the username as strings). > > Result: > > Invoice { > #username : 'user', > #currency : 'eur' > } > > Instead of: > > Invoice { > #username : 'user', > #currency : Currency { > #unit: 'Euro' > } > } > > Then during the import I want to transform the currency into a class > again. (For example `Currency fromAbbreviation: stonInput`). OK, that is an understandable example. But why exactly do you want Currency to be serialised differently ? You don't want too many instances ? You want all instances to be #== ? Is Currency too big ? You want to allow humans to edit the STON file ? What ? Why ? You can easily make it Currency['Euro'] or even Currency[#Euro] like it is already done for a number of built-in classes. The last example that I gave solved the 'too many instances', make them #== issue. If it is size, that got covered too, but you must solve the problem of how the receiving end will resolve the reference then. But since that is all no good, there must still be another requirement. > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

May 17, 2017

Re: [Pharo-users] Loading Glorp+PostgreSQL

by Pierce Ng

On Tue, May 16, 2017 at 11:58:50AM +0200, Sven Van Caekenberghe wrote: > I am bringing my Reddit example back up to date (https://medium.com/concerning-pharo/reddit-st-in-10-cool-pharo-classes-1b53…) for an upcoming Pharo Booklet. Hi Sven, I've adapted your Reddit application to work with Glorp-SQLite. It was pretty much simply subclassing RedditDatabaseResource and wiring up #newGlorpSession. It's a nice demo of Glorp's pluggability. Pierce

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Cyril Ferlicot D.

On 17/05/2017 15:17, Sven Van Caekenberghe wrote: > > > OK. > > But don't go too far in writing actual code. I want to understand the use case at a high level (like how you started), then I can try to find how/if STON can do what you want. Right now, you are already too deep into a possible solution. > > If I have to give a really simple use case. Imagine an invoice. The invoice has the name of the customer and the currency used as a class. During the export of the invoice you do not want to export the currency as a class but as a String. So if I have an Invoice instance like this: username: 'user' currency: Currency[Euro] I want to transform the currency to a string during the export. (and keep the username as strings). Result: Invoice { #username : 'user', #currency : 'eur' } Instead of: Invoice { #username : 'user', #currency : Currency { #unit: 'Euro' } } Then during the import I want to transform the currency into a class again. (For example `Currency fromAbbreviation: stonInput`). -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 17, 2017

Re: [Pharo-users] Ston feature idea?

by Sven Van Caekenberghe

> On 17 May 2017, at 15:11, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 17/05/2017 14:55, Sven Van Caekenberghe wrote: >> >> >> The use of #stonAllInstVarNames works in limiting what you write out (there is even a unit test based on STONTestUser3). >> >> But you seem to want to do something else, you want to write the others ones out in a different way. >> >> What I tried to explain is that that is generally not needed, if you customise the value of #variableToCustomise (that is one level deeper). This is what I did in the example. >> >> Since you can't or won't explain your use case better, I really can't help, can I ? >> >> > > I don't really have the time right now but later I'll try to write a > simple example. OK. But don't go too far in writing actual code. I want to understand the use case at a high level (like how you started), then I can try to find how/if STON can do what you want. Right now, you are already too deep into a possible solution. > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

May 17, 2017