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

[Cameron Sanders via Pharo-users]

--- Begin Message ---

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 <camsand...@aol.com> 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 <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 ---