Re: [Pharo-users] Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

[Cameron Sanders via Pharo-users]

--- Begin Message ---

*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 <step...@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
>
>

--- End Message ---