The PEAK Developers' Center   Diff for "IntroToPeak/LessonFour" UserPreferences
HelpContents Search Diffs Info Edit Subscribe XML Print View Up
Ignore changes in the amount of whitespace

Differences between version dated 2004-10-26 15:50:10 and 2005-02-03 13:16:14 (spanning 9 versions)

Deletions are marked like this.
Additions are marked like this.

python interface library, available from
[]. Or use your operating
system's package facility if it has one (for example, on FreeBSD
you could do "cd /usr/ports/database/py-PySQLite; make install".
you could do "cd /usr/ports/database/py-PySQLite; make install" and on Gentoo Linux you can "emerge pysqlite").

}}} Ah, good. Looks like "customers" is probably the table
we want. Let's see if we can find out more about it. {{{
1> \describe customers
Feature not implemented yet.
}}} That's not as helpful. Perhaps what we need is that "verbose"
option on the general \describe command. {{{

our new database.
First, we'll need a reference to the database as a class
variable in our DM. {{{
variable in our Data Manager. {{{
customerdb = binding.Obtain(PropertyName('corporate.customerdb'))

Next, we'll need to change our `_load` method to get the right
message, using auxiliary info from the customer data base. Remember,
our database connection object is callable; if we pass it an SQL
command, we'll get back an interable cursor containing the results:
command, we'll get back an iterable cursor containing the results:
    def _load(self, oid, ob):

        return {'forname': oid, 'text': m}
}}} What's that funny looking `~` doing in front of our database
call? The `ICursor` interface, which is an interface supported by
the type of object returned by a DM, defines the python unary
the type of object returned by a DM (Data Manager, not to be confused with Domain Model),
defines the python unary
negation operator to be the function `oneOf`. `oneOf` will raise
an error if there is anything other than one row accessable from
the cursor. If there is only one row, it returns it.

the error we'd otherwise get when it tried to load the non-existent
`forname`. This is logical, but the quirk that makes the app
still work is that our storage implementation for the message
database will ''udpate'' the message even though we did a
database will ''update'' the message even though we did a
``newItem`` to get the object. This is not something that a
good app design should depend on, so we'll fix it right in a

As long as we're rewriting anyway, we might as well get rid of that
clunky file and move to a real database for our messages. Perhaps
someday they'll move into a table on the corporate database, but
for now we'll stick with our SQLite database, since has proven its
for now we'll stick with our SQLite database, since it has proven its
worth so far.
We'll replace the `messagefile` configuration item in our `hello` file

the database.
We do, however, now actually need different methods for the `_new`
versus `_save` case, because the SQL commands to udpate a record
versus `_save` case, because the SQL commands to update a record
are very different from those used to add a record.
To implement a `get` method similar in efficiency to the one we had

        else: return
Now our `print` line in `` becomes:{{{
Now our `print` line in `` becomes:{{{
print >>self.stdout, self.Customers[name].greeting()
}}} Which is more Demeter-proof anyway.

ShowText of this page
EditText of this page
FindPage by browsing, title search , text search or an index
Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck