Simpycity now available on Github
Posted Tuesday Jul 20th, 2010 05:43pm
by Aurynn Shaw | Permalink



Following up on our brand-new Simpycity 0.3.1 release from earlier today, you're now able to get hold of Simpycity via the ever-popular code-sharing platform GitHub.

Check us out @ GitHub, and track all the Command Prompt projects!

---

Announcement: Simpycity 0.3.1 Released
Posted Tuesday Jul 20th, 2010 01:13pm
by Aurynn Shaw | Permalink



Following up on the blog post covering the new coolness in 0.3, and better docs on working with Simpycity, we've just released Simpycity 0.3.1, our best release yet!

Simpycity can be downloaded from our Wiki, and our code is available from the Subversion repository.

Finally, starting today, all new releases of Simpycity are available on the PyPI package index, and Simpycity installable via:

$ easy_install Simpycity

---

Active Object in Simpycity
Posted Tuesday Jul 20th, 2010 01:04pm
by Aurynn Shaw | Permalink



Simpycity is, as we've previously covered, a small library that permits for the direct mapping of arbitrary SQL statements to Python callables.

This power allows for the development of complex representations that do not need to directly map to the underlying database representation.

This differs from most conventional ORM technology, which follows the ActiveRecord pattern.

Simpycity was implemented in this way for a great many reasons, first and foremost that the Active Record pattern is not the best representation of your data to your application logic. Should the application need to be aware of underlying data relationships? Should
the application be aware of foreign keys, structures, and other underlying constructs?

Or should the application be able to interact with the data in a form that is logical, and sensible to the application, without needing deep
knowledge of underlying representations?

We thought so, and Simpycity, and a concept more along the lines of Active Object is our result.

Disparate Representations

Simpycity, instead of writing SQL for you via query generators, requires that the developer write SQL by hand.

The reason for this is that database representations are not generalizable into object relations - this disconnect is the entire
reason behind the object-relational difficulties.
A proper object representation encapsulates all the possible information about a method in a single location, as well as all the necessary
methods to act on that data. A single object then represents a single quantum of data.

However, for a relational system, normal form requires that disparate pieces of information are further broken down, into points of absolute
truth about the data. A person's name, for instance, is a point of absolute truth, and should exist in only a single place in the database,
whereas a person's name could exist in several places in an Object system, in a sensible manner.

The disparity comes in that a Person, in terms of business requirements, is rather different from a Person in SQL terms, to the point where it would not be sensible to represent a database Person as an object Person - Address information, birthdate, all sorts of ancillary data that would normally be present isn't, per correct normal form.

Simpycity works to avoid this, by allowing for business models that have little if anything in common with the underlying table structure,
allowing for proper normalization as well as useful business objects.

Forging Anew

As Simpycity does not impose the database structure on your objects, it can't immediately provide the functionalities of .new() in the way a conventional ORM can - even though we've seen Simpycity handle the .save() feature brilliantly.

Instead, if you instance a Simpycity model, not from the database, you get precisely and only a Simpycity instance. As it's not connected to a known set of database data, all the functions and other associated items have no way of operating, and the model just sits there, forlorn and empty.

But since we have to match the Active Record pattern, how would we go about providing .new() in Simpycity?

Here's how we do it:

Given a standard model that looks like this,

class model(ctx.Model()):
     table = ['id','name']
     __load__ = ctx.Function("load_obj", ['id'])

We're able to do simple and basic load operations. Right?

But, to create a new object, the pattern more resembles:

class model(ctx.Model()):
...

new = ctx.Function("new_obj",['name'], return_type=model)

Which allows for the external interface of:

import yourmodel
o = yourmodel.new("Some name")
o.commit()

Providing a clean and sensible model API, following the ActiveRecord pattern,
but still offering all the power of Simpycity.

Twisty Little Properties

Another very nifty capability of ActiveRecord systems is that of reflection, automatically retrieving the far end of a foreign key constraint. This allows for useful functionality like

aModel.comments

correctly reaching across the one-to-many relationship and pulling all the comments.

As Simpycity doesn't directly map tables, capabilities such as this aren't directly implemented in Simpycity.
However, since we do realize that business objects need to perform similar tricks and load data in via properties, we added specific support for this into Simpycity.

But, since Simpycity is entirely callable based, we had to be able to support this feature with our existing metaphors. To that end, we included a simple function that will take any Simpycity callable (or any callable, really), interrogate its argument list, and handle argument mapping as you'd expect.

Using this feature is as simple as:

    from simpycity.helpers import prop
    
    class myTextObject( ctx.Model() ):
        table = ['id', 'value']
        __load__ = ctx.Function("textobject.by_id",['id'])
        comments = prop( get=ctx.Function("textobject.comments", ['id']) )
        
    mto = myText(1)
    comments = mto.comments

Easily allowing for sensible properties to be created, based entirely on clean Simpycity code. Properties created in this way even support set and delete functionality, identical to a standard property, allowing for property accessors to easily manipulate the database layer.

As a note, prop() is a new feature in 0.3.1. 0.3.0 and below should use

    from simpycity.helpers import sprop
    
    class myTextObject( ctx.Model() ):
        ...
        comments = property(sprop( get=ctx.Function("textobject.comments", ['id']) ))

Obviously not as clean, and not as capable. You should upgrade ASAP.

Next

We've stabilized the API, made everything work through the consistent Context interface, and have built a powerful callable-based model infrastructure for all sorts of application development.

So what's next for Simpycity? Well, some of the things we're planning on include breaking the Model object away from psycopg2 dependency, allowing us to use other PG drivers (such as pg8000), as well as opening up the Model protocol we've defined for other contexts - file access, for instance. Anywhere that an application needs to represent a complex underlying structure as a simple object, the Model could be used.

More in the future, we're really looking forward to integrating Simpycity callables with Django and SQLAlchemy model objects, using Simpycity to provide strong, clean functional and raw query support in those environments. And vice-versa as well: Binding a SQLAlchemy or Django ORM chain to a Simpycity object, using it to populate an object, and building even more complex, effective business objects for your application.

Even farther afield, we've been looking at integrating query generation to Simpycity. There's a lot of boilerplate SQL that needs writing, and being able to hand it to an elegant, PostgreSQL-focussed abstraction would be, we think, ideal.

As always, Simpycity is available on our Wiki, and our code can always be checked out from our Subversion repository.

Finally, Simpycity is easily installed from the PyPI index, using easy_install Simpycity.

---

Cool Features I'm Looking Forward to in PostgreSQL 9.0
Posted Tuesday Jul 13th, 2010 11:46am
by Aurynn Shaw | Permalink



Recently, I was able to attend the local PostgreSQL community meeting here in Portland, and the topic du jour was covering the nifty and interesting features that are found in PG 9.0.
Confessing that I haven't really been paying close attention to what's new in 9.0, the talk was incredibly interesting - covering a range of new features in 9.0.

The ones I'm really excited about are:

/contrib/passwordcheck

This newly-added contrib module adds that feature that sysadmins are going to love - being able to add stronger password-based restrictions to the default PG password requirements.

You know the sort I mean - must be a mixture of capitalized and non, must be at least one number, must be at least n digits long. This is exceptionally useful if you're in an environment with strong password requirements.

samehost and samenet

These pg_hba.conf administration conveniences allow you to match any IP address that the server owns (same host) or any subnet that the server is a part of (same net).
This'll be very useful for any multi-homed DB server that needs to listen on all its interfaces; as well as providing an easy way to just say "all my peers" without explicitly needing to remember and declare the IP subnet.

Parameter change logging

This is a fairly useful change for anyone who's tried to figure out what changed during the last reload of PG. Instead of wondering, you can now configure a logging setting to report what parameters from the config were changed, what they were changed to, and what changes require a full restart before they can be used.

EXPLAIN now machine-readable

This is an amazingly useful feature, especially when combined with auto_explain - you'll now be able to get explain output in XML, JSON or YAML, allowing for easy parsing, manipulation and comparison of the EXPLAIN output.
This also allows for transformation of the output - easily converting it to HTML, for instance. Easy comparison before and after an index is created, simplifying programmatic discovery of indexes.

WHEN clause in triggers

WHEN clauses in triggers add a new level of power to the trigger system, by allowing PG to handle the large block of IF statements we always have in our triggers.
This should allow us to see a major performance boost for any conditional triggers, since PG doesn't have to descend to the trigger stored procedure for every modification.

NOTIFY now takes a string argument

Instead of just getting the notification from your database, you'll now be able to pass an optional string. With a clever sproc and some clever string formatting, you can now pass useful information to the NOTIFY receiver, saving yourself from excess work in figuring out what's changed.
Simpler event-driven programming? Never a bad thing.

Named parameters in stored procedures

This is huge for Simpycity. On 9.0, we can now handle argument naming in a whole new way:

SELECT * FROM my_func(param='string', another_param=3);

Being able to run queries like this will easily simplify Simpycity - just name your arguments the same in both Python and PostgreSQL, and everything will Just Work, clean and simple.

Keep an eye out for this update - I can't wait to add support in Simpcyity. Keep an eye out for the updates on the Simpycity project page

So Much More!

Of course, this is just a subset of the interesting things - the bits I'm really looking forward to.
You should go have a look at the whole list, easily found on the Illustrated Postgres 9.0 Wiki.

---