Hey, all.. One of the things that I find SUPER necessary when developing an app is to be able to grab data from somewhere else and quickly and easily work on it from my machine. For instance, when I get a bug report that smells funny, the first thing i sometimes do is run a script that grabs the production data, and populates my local database with that data. i am fleshing out a project that i would really like to use Teapot (REST) for. i could then write several front ends in whatever framework/language. I was thinking about using Voyager, but the problem is, the data is VERY relational (see below, if interested).. objects are linked to each other fairly tightly. I don’t know if this would be the way to handle the data, as there would be lots of duplication using mongodb as a datastore. Of course, my first thought is Gemstones, but I don’t know how to grab the production data and pull it into my local development system. Does anyone have any thoughts on this? For those curious about the data design, i am setting up a REST server for an collaborative internet radio application… - there would be a global pool of stations (just streaming urls with metadata, really) - each user can select from or contribute to the global pool - users can add tags to stations (or search through the global stations based on tags) - users can attach comments to stations not complex or intimidating at all, and super easy to model in smalltalk, but not sure about how to store data so that I can quickly grab production data and troubleshoot if if necessary. Thanks! ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
Sergio, You might take a look at the talk I gave on Voyage/Tugrik at ESUG(slides[1], video[2]). The project is in a functional, but roughed out stage --- but the main idea behind it is that with GemStone as the db serve, you are dealing with Smalltalk objects on both the client and server ... Voyage Server Blocks allow you to write code on the client that is executed against objects on the server ... STON is used for serialization/materialization ... Voyage Server Blocks let you blur the lines as to where do the objects live and where does the code execute ... Currently Tugrik uses MongoTalk as the model for Voyage-style interactions between client and server, but Voyage Server Blocks (which are not a feature of MongoTalk) may be useful on their own ... In the talk, I mention that I am looking for partners in pushing
Voyage/Tugrik forward, because I think that real users with real
problems are needed to drive the project forward --- I am more
interested in meeting real developer needs, than building
something that makes me happy:) MongoTalk was originally chosen to make it practical for folks already using Voyage/Mongo to easily kick the tires on Voyage/Tugrik, but I don't think that it is necessary to stay coupled to MongoTalk. Michal Balda is looking at something "simpler than Tugrik+MongoTalk+Voyage" and I wish that I could be in Zurich to see his presentation next week[3]:) as I want to support his efforts ... Dale [1] http://www.slideshare.net/esug/tugrik-a-new-persistence-option-for-pharo [2] https://www.youtube.com/watch?v=YwlUdRaqTwE&feature=youtu.be [3]
http://forum.world.st/ANN-Zurich-Smalltalk-Meetup-Nov-8th-2016-tt4919147.html On 11/01/2016 08:54 AM, sergio ruiz
wrote:
|
Okay.. is Voyage ready to rock and/or roll? is today your birthday? for some reason, i got a notification of several things on my machine today.. one of those being your birthday.. if so, happy birthday! if not.. happy un-birthday! On November 1, 2016 at 2:16:57 PM, Dale Henrichs ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
On 11/1/16 12:28 PM, sergio ruiz wrote:
Voyage is definitely ready to rock and roll ... Voyage/Tugrik is ready to be rocked ... it is functional and passes the tests (on Pharo5.0). For this project, I want to make progress based on feedback from users ... there are lots of different directions that could be taken from this starting point and I want to be driven by user feedback ... so if you are willing to provide feedback I am willing to work with you ... The only change that I think I need to make is to improve the session pool logic ... it works fine, but the session boundary is not quite at right level to make the best use of GemStone sessions ... With "direct access" to the server objects via Voyage Server Blocks I think that query api provided by MongoTalk may not be that interesting, but this is the kind of information I am looking for from users ... If MongoTalk _is_ interesting then you should know that I did not try to fill out the full MongoDB query language, yet ... I implemented the features excercised by tests, so if you hit something that you you find lacking then I will plug the gap ... it is relatively straight forward to implement the MongoDB query language (except for the bits that rely directly on the javascript language:) so it shouldn't take too long to fill in holes:) Tomorrow is my birthday, thanks:) Dale |
i think that for my current project, I want to move REALLY quickly. so it might not be a good fit, but i would totally like to play around with it under different use cases. ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
Keeping data in image with a STON export would be good enough: On Wed, Nov 2, 2016 at 3:21 PM, sergio ruiz <[hidden email]> wrote:
|
Hmm… i need to look at this .. i can just burp out all my objects with ston and suck them back in on the local machine.. On November 2, 2016 at 10:25:51 AM, [hidden email] ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
Fuel is another option , though ston will be more readable because ston is text fluel is binary . SQLite is another one . You actually have a ton of options here. You can even make your own binary or text format if want , it's easy.
On Wed, 2 Nov 2016 at 16:30, sergio ruiz <[hidden email]> wrote:
|
In reply to this post by sergio_101
> On 2 Nov 2016, at 15:29, sergio ruiz <[hidden email]> wrote: > > Hmm… i need to look at this .. > > i can just burp out all my objects with ston and suck them back in on the local machine.. Just try it ;-) STON put: myObjects onStream[Pretty]: fileStream. STON fromStream: fileStream. https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/STON/STON.html STON has already seen quite some usage, so you should be good. > On November 2, 2016 at 10:25:51 AM, [hidden email] ([hidden email]) wrote: > >> Keeping data in image with a STON export would be good enough: > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 |
Use these methods in your class. loadStonFromFile: aDataFilenameString | data | data := STON fromStream: ((self dataFileNamed: aFilenameString) readStream). ^data persistAsSton: anObject toFile: aDataFilenameString
(self newDataFileNamed: aFilenameString)
writeStreamDo: [ :out | out << (STON toString: anObject) ] dataFileNamed: filename "For an existing file" ^ (FileLocator imageDirectory / 'data' / filename) fullPath asFileReference newDataFileNamed: filename | file | file := (FileLocator imageDirectory / 'data' / filename ) fullPath asFileReference. file writeStream close. ^ file Usage: "Saving" self persistAsSton: someDataStructure toFile: self newDataFileNamed: 'persist.dat' "Loading" someDataStructure := self loadStonFromFile: self dataFileNamed: 'persist:dat' HTH Phil On Wed, Nov 2, 2016 at 3:38 PM, Sven Van Caekenberghe <[hidden email]> wrote:
|
Hum, use this instead: Usage: "Saving" self persistAsSton: someDataStructure toFile: 'persist.dat' "Loading" someDataStructure := self loadStonFromFile: 'persist:dat' Well, depends if you want to write to same file, different file etc, but this will get you on the right track On Wed, Nov 2, 2016 at 5:20 PM, [hidden email] <[hidden email]> wrote:
|
Looks like I might stick with STON.. I am not really worried too much about execution time or anything.. Need to look at one more thing.. If a user has say.. many stations.. meaning that they have an OrderedCollection of Stations.. I need to check how that gets serialized, and what happens when it gets pulled back in.. I will play with it this afternoon.. Thanks! On November 2, 2016 at 12:24:48 PM, [hidden email] ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
In reply to this post by philippeback
Yes, I will do this.. i bet i can even serve it up via http, and pull it directly from my working image.. Thanks! On November 2, 2016 at 12:24:48 PM, [hidden email] ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
In reply to this post by sergio_101
There is a chapter in the Enterprise Pharo book on STON that may be of some help to you
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/STON/STON.html
The book also talks about other storage mechanisms, see http://files.pharo.org/books/enterprise-pharo/ HTH, -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
|
The funny thing about STON is that, as a professional developer, I am so used to the whole world being a “hey, look! we have this too!!” world, that I never looked into it at all.. I should have knows that that Pharo/Smalltalk community would, instead of “me too” would say.. “look, here’s a cleaner, simpler, and more flexible way to do the thing..” thanks, pharo/smalltalk community for being simple/flexible/clean ! On November 2, 2016 at 1:45:07 PM, Johan Fabry ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc (852 bytes) Download Attachment |
Hi, I'm using STON for my Grafoscopio[1][2] project with pretty good results. It's flexible, readable and well supported and document. Better that JSON! Pretty recommended. [1] http://mutabit.com/grafoscopio/index.en.html[2] http://smalltalkhub.com/#!/~Offray/Grafoscopio Cheers, Offray On 02/11/16 12:50, sergio ruiz wrote:
|
A question I was meaning to ask, how efficient is STON at storing references , lets say I have an object that has instance variables that references another object and that object has a instance variable that references another object etc. Where exactly STON stops , or are there any limitations
On Wed, Nov 2, 2016 at 7:58 PM Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
|
As far as I know it doesn't "normalize" references, as Fuel does. The alternative is to have a Fuel serializer that serializes Fuel objects in STON format instead of binary :D Esteban A. Maringolo 2016-11-02 15:14 GMT-03:00 Dimitris Chloupis <[hidden email]>:
|
In reply to this post by kilon.alios
Basically, STON walks the graph noting each object it sees. When it encounters the same object again, it outputs a reference. Object equality is of course #==
References are integers, indexes into the list of objects seen, ordered by walking depth first. Sven > On 2 Nov 2016, at 19:14, Dimitris Chloupis <[hidden email]> wrote: > > A question I was meaning to ask, how efficient is STON at storing references , lets say I have an object that has instance variables that references another object and that object has a instance variable that references another object etc. Where exactly STON stops , or are there any limitations > > On Wed, Nov 2, 2016 at 7:58 PM Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > Hi, > > I'm using STON for my Grafoscopio[1][2] project with pretty good results. It's flexible, readable and well supported and document. Better that JSON! Pretty recommended. > > [1] http://mutabit.com/grafoscopio/index.en.html > [2] http://smalltalkhub.com/#!/~Offray/Grafoscopio > Cheers, > Offray > > On 02/11/16 12:50, sergio ruiz wrote: >> The funny thing about STON is that, as a professional developer, I am so used to the whole world being a “hey, look! we have this too!!” world, that I never looked into it at all.. >> >> I should have knows that that Pharo/Smalltalk community would, instead of “me too” would say.. “look, here’s a cleaner, simpler, and more flexible way to do the thing..” >> >> thanks, pharo/smalltalk community for being simple/flexible/clean ! >> >> On November 2, 2016 at 1:45:07 PM, Johan Fabry ([hidden email]) wrote: >> >>> The book also talks about other storage mechanisms, see http://files.pharo.org/books/enterprise-pharo/ >>> >>> HTH, >>> >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: http://bit.ly/29z9fG0 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> http://www.Village-Buzz.com >> http://www.ThoseOptimizeGuys.com >> http://www.coffee-black.com >> http://www.painlessfrugality.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 > |
In reply to this post by Esteban A. Maringolo
> On 2 Nov 2016, at 19:19, Esteban A. Maringolo <[hidden email]> wrote: > > As far as I know it doesn't "normalize" references, as Fuel does. What does that mean ? See my previous mail for an explanation for what STON does - it handles shared and cyclic references correctly. > The alternative is to have a Fuel serializer that serializes Fuel objects in STON format instead of binary :D > > Esteban A. Maringolo > > 2016-11-02 15:14 GMT-03:00 Dimitris Chloupis <[hidden email]>: > A question I was meaning to ask, how efficient is STON at storing references , lets say I have an object that has instance variables that references another object and that object has a instance variable that references another object etc. Where exactly STON stops , or are there any limitations > > On Wed, Nov 2, 2016 at 7:58 PM Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > Hi, > > I'm using STON for my Grafoscopio[1][2] project with pretty good results. It's flexible, readable and well supported and document. Better that JSON! Pretty recommended. > > [1] http://mutabit.com/grafoscopio/index.en.html > [2] http://smalltalkhub.com/#!/~Offray/Grafoscopio > Cheers, > Offray > > On 02/11/16 12:50, sergio ruiz wrote: >> The funny thing about STON is that, as a professional developer, I am so used to the whole world being a “hey, look! we have this too!!” world, that I never looked into it at all.. >> >> I should have knows that that Pharo/Smalltalk community would, instead of “me too” would say.. “look, here’s a cleaner, simpler, and more flexible way to do the thing..” >> >> thanks, pharo/smalltalk community for being simple/flexible/clean ! >> >> On November 2, 2016 at 1:45:07 PM, Johan Fabry ([hidden email]) wrote: >> >>> The book also talks about other storage mechanisms, see http://files.pharo.org/books/enterprise-pharo/ >>> >>> HTH, >>> >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: http://bit.ly/29z9fG0 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> http://www.Village-Buzz.com >> http://www.ThoseOptimizeGuys.com >> http://www.coffee-black.com >> http://www.painlessfrugality.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 > > |
Free forum by Nabble | Edit this page |