Stephan, First let me say, if i can figure out the proper markdown to get color-coded inset-code looking right, i would gladly improve the DebrisDB description with more simple examples. Additionally, i am happy to answer questions in email. I will also consider a few video tutorials soon. Now, most importantly: I checked in a new version. There was a gross error (#halt) that I accidentally checked in during recent edits ... that ... ahem, that would have caused several tests to fail. My apologies. I defined a new Example-Contacts that will create a folder under the user home -- at least it works with Pharo on a Mac -- named ContactsApp/data and in that folder will leave a file called FaContactsDB.fdb after you have run the tests. The example consists of these classes: *FaContactsDB* -- the class you use to get ahold of sessions to your application-specific conceptual DBs. It subclasses from FaDemoContactsAppDB, which subclasses from FaClassNamedDB. The only reason to create FaDemoContactsAppDB (or your specific version) is so that you can redirect all of your #session requests to an entirely different lookup mechanism. One can also redirect on a DB specific basis. Saying 'FaContactsDB session' is the same as '(FaDBSessionServer instance getSession: #FaContactsDB)' ... given that FaClassNamedDB uses the classname. At Debris, our code is a little different, and we use the db-session lookup key of #contactsDB for this example. This becomes the name prefix for your fuel-file by default. So we can adjust this if desired. *FaDemoContactsAppDataHub* -- see the class-side method #instance. Its #login: method assumes one repo... and configuration of multiple repos is easy, but i created several new classes in a hurry when i carved our Glorp-like-sessions away from our main code base. The "basic hub" this one uses is one of those "in a hurry" classes, and i like the new perspective it has given me. Admittedly, these are not well tested, but as you can see, simple, and the tests seem to work. *FaDemoContactsContact* -- this is the only application specific class in this demo, with a very verbose name. This is the contact class that has a name, address and phone number. *FaDemoContactsTests* -- this class illustrates how to interact with glorp sessions. Good luck, and please don't hesitate to inquire if you need more info or encounter more problems. -Cam On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan@stack.nl> wrote:

Hi Cam

Interesting. The brain-dead-sample is a bit difficult to get started with. Would you care to talk a bit more about how to do something simple with it? An addressbook, with people having addresses and phone numbers might be an easy to use example.

Cheers, Stephan

*Download version 15 -- see http://smalltalkhub.com/#!/~Debris/DebrisDB <http://smalltalkhub.com/#!/~Debris/DebrisDB>*. Minor changes to the newest example in DebrisDB: the new version renamed all the classes of the DebrisDB-Example-Contacts package to have 'FaDemoContacts' as the starting pattern. Also, the folder created under the user home is named FaDemoContactsApp. Also fixed: i just spotted that #any is defined by Grease, so I modified two methods to use #anyOne, until we add a configuration for this package and/or close the gap between gemstone and pharo. Finally, i added a dictionary interface to the class side of FaDemoClassNamedDB and two test methods to FaDemoExamplesTestCase that let you see how you might use a dictionary interface with this glorp-like backend. If you need ONLY a dictionary interface, then perhaps this toolkit is not what you need; also note that real-Glorp's relational mapping will force you to handle the varied-type values of these associations. If you are unfamiliar with Glorp, take a look at the FaDemoContactsTests to see some simple interactions, and/or find a Glorp manual somewhere. Once you have defined your login system (see the data-hubs in the examples provided), interactions with Glorp sessions are simple. *MyDataHub login: myUserCredentialRecord.* "normally do this once for the user web-session and have a different sessionMapRetrievingBlock than is provided in this default framework to get the map from user-specific web-session-data. (See FaDBSessionServer sessionMapRetrievingBlock -- and the map is just a dictionary of DB-key to a block to yield a glorp-like-session. However, the blocks could as easily serve up connections to MongoDB, etc. so that one could have MyOneMongoDB session, MyTwoMongoDB session, etc. to handle logins)" *MyApplicationDB session inUnitOfWorkDo: [ :session | session registerAll: listOfMyObjects ]. *"will saveDB upon completion" *retrievedList := MyApplicationDB session readManyOf: MyObjectsClass.* "may be unordered, may be a bag, therefore, if you just want one, don't send it #first, instead use #anyOne or if grease is loaded, #any, or instead use #readOneOf:" *retrievedList := MyApplicationDB session readManyOf: MyObjectsClass where: [:each | each someAspect = someValue ].* See #FaAbstractGlorpSession to see supported Glorp interface. So what about using a session as a Dictionary? Simple. Simply store Associations. See the method #test2BasicSessionStorageOfAssociations. Then see the following test method added just as an example of using Glorp-sessions as dictionaries -- see the class methods of FaDemoClassNamedDB. *--* test3ConceptualDBsAsDictionariesExample | value | FaDemoApplicationDataHub login: nil. FaDemoTwoDB at: #2 put: 'string with a 2 in it.'. FaDemoTwoDB at: #2 put: 2. self assert: (FaDemoTwoDB at: #2) = 2 description: 'The value should be 2.'. FaDemoTwoDB at: 'Hello Jack' put: 'My name is Bob!'. FaDemoApplicationDataHub releaseAll. FaDemoApplicationDataHub login: nil. self assert: (FaDemoTwoDB at: #2) = 2 description: 'The value should be 2.'. self assert: (value := FaDemoTwoDB at: 'Hello Jack') = 'My name is Bob!' description: 'Upon reload the data should be present.'. -- Good luck, and my apologies for the defects that prevented default tests from working! -Cam On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan@stack.nl> wrote:

Hi Cam

Interesting. The brain-dead-sample is a bit difficult to get started with. Would you care to talk a bit more about how to do something simple with it? An addressbook, with people having addresses and phone numbers might be an easy to use example.

Cheers, Stephan