On Tue, May 28, 2013 at 12:37 AM, Kaare Rasmussen <[email protected]> wrote:
> **
> Hi Chris
>
> Thanks for releasing the code. Some initial feedback, based on the
> description. I haven't tried the module(s) yet.
>
> Name. Why not Pg::Object and Pg::Object::Simple.
> The description leads me to believe that PGObject would be better as a
> Moose role. Especially "Most developers will want to use more functional
> modules which add to these functions." and the note about state handling.
>
I thought about it, but there is already a Pg.pm which is not officially
maintained, but fills a very different role. I figured might not be great
to send mixed messages there.
The idea is that the PGObject namespace would be a set of related systems
of integrating stored procedures into object-oriented Perl programming.
The docs might not be as clear as I would like so I will probably see what
I can do to make them clearer. You aren't entirely off-base, but hopefully
this will make things clearer.
PGObject interface systems can be thought of as consisting of a top half
and a bottom half. The bottom-half is db-facing and provides interfaces
which interface systems use to interact with the database. The top-half
consist of developer API's for integrating these into objects. So
PGObject and PGObject::Simple actually serve different functions.
>
> PGObject::Simple looks like a class consuming that role.
>
Not quite (I can see how it looks that way though). PGObject itself is
essentially a singleton which glues three things together:
1. the database
2. "top-half" modules like PGObject::Simple.
3. PGObject-aware types. This support is getting stronger for 1.1, and
requires storage in the module of some global state (state intended to be
more or less run-time configuration parameters instructed by other modules).
The interfaces provided are therefore essentially to allow the top half
modules to talk to the database, and for PGObject-aware types to plug
themselves into the process. Top half object systems and roles then use
these services to fill their needs. PGObject::Simple for example has no
function_info function exposed to the world even though it uses this as an
integral part of its own operation (there really wouldn't be a point).
The reason to release PGObject::Simple is that it is almost compatible with
what we did with LedgerSMB::DBObject in LedgerSMB 1.3. It is a complete
class in itself that can be used as a base class relatively easily with a
great deal of transparency and very little abstraction except when it comes
to stored procedures. It is sort of the quick and dirty approach. It
would not take much effort to either wrap our existing call structure
around what is in PGObject::Simple, or just port to it. In general it has
some very good things about it along with the bad, and it makes it very
easy to build Perl scripts which interact with PostgreSQL databases.
Obviously this isn't really that great in some cases. So in 1.4 we wrapped
this in LedgerSMB::DBObject_Moose which is a role. I am looking at
replacing this with PGObject::Simple::Role, which wraps PGObject::Simple
functionality in a Moo role so it can be incorporated in Moose and
non-Moose applications with a minimum of dependencies.
So what I am getting at is that PGObject and PGObject::Simple encapsulate
different functionality with different audiences in mind. There is some
overlap in terms of calling stored procedures, but the overlap there
somewhat deceptive. PGObject encapsulates the lower-level database
operations for developer-facing models and integrated types.
Developer-facing models encapsulate stored procedure conventions.
Integrated types allow you to say "I want this class to be instantiated on
every date value retrieved from the database."
Does this help make things clearer? Or is it still confusing?
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
