Smalltalk › Pharo › Pharo Smalltalk Users

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Stephan Eggermont-3

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

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

Pharo Smalltalk Users mailing list

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

i'll be glad too. Let me check in an update with such an example.

On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <[hidden email]> 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

Pharo Smalltalk Users mailing list

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

In reply to this post by Stephan Eggermont-3

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 <[hidden email]> 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

Pharo Smalltalk Users mailing list

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

In reply to this post by Stephan Eggermont-3

One note about the tests of FaDemoContactsTests: previously i thought the tests of TestCase were run in alphabetical order. So three of tests may fail if they run before #test1AddingItemsToDB has run. On subsequent runs, the tests should all go green.

-cam

On Fri, Feb 13, 2015 at 5:36 PM, Cameron Sanders <[hidden email]> wrote:

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 <[hidden email]> 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

Pharo Smalltalk Users mailing list

Re: Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

In reply to this post by Stephan Eggermont-3

Download version 15 -- see 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 <[hidden email]> 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