DB Migrations Architecture

Hi All-

I have finally completed a working version of my migrations system. I  
am calling it MP, for "Migrations for PHP", and it is a generalized  
solution not tied to any framework or ORM. However, it has a full API  
and is actually intended to be integrated with such systems.

I've got the project hosted on GitHub: http://github.com/apinstein/mp/tree/master

A little blurb on it:
MP keeps your migrations in order.

MP is a generic migrations architecture for managing migrations  
between versions of a web application.

It can be used to migration database schemas as well as perform  
arbitary code during upgrades and downgrades.

HOW IT WORKS
MP keeps track of the current version of your application. You can  
then request to migrate to any version.

MP also has a "clean" function which allows you to reset your  
application to "version 0". There is a clean() callback
which allows you to programmatically return your application to a  
pristine state when migrating with the "clean" option.
------

It would be pretty trivial to integrate with propel so that it can be  
used from propel-gen or maybe even a separate wrapper like propel- 

maximeleonard <at> hotmail.fr has invited you to have a 3D avatar chat

Re: Access to Propel Trac

Hi Peter,

Sorry for delay.  I've created a Trac account for you:

username: pkw
password: peter405

You can change your password here:  http://phpdb.org/account/

You should be able to post tickets with those creds; let me know if you 
have any trouble.

Hans

webpost <at> tigris.org wrote:
> Hans,
>
> My email is pkwooster <at> gmail.com and the desired username is either pkw or pkwooster.
>
> Thanks/peter
>

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=2102671

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

Access to Propel Trac

How do I get access to report or update bug reports on the propel trac?  There isn't a "register" button like
most others have.

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=2070774

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

Re: PostgreSQL Specific optimization in Criteria

No gripe from me if all existing tests pass

On Sat, Apr 25, 2009 at 11:29 PM, Cameron Brunner
<cameron.brunner <at> gmail.com> wrote:
> Anyone object if we start adding db specific optimizations in? specifically this
>
> instead of doing IN (val1,val2,val3etc) you do IN (SELECT
> (ARRAY[val1,val2etc])[i] FROM generate_series(1,count($total in the
> list)) i)
>
> turned a query i was doing in postgres from taking 81secs to 650ms
> since the query planner had more data it could use
>
> --
> Cameron Brunner
>
> Want a better web browser?
> http://www.spreadfirefox.com/?q=affiliates&id=182780&t=1
>
> ------------------------------------------------------
> http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1922621
>
> To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].
>

--

-- 
Tony Bibbs
Phone: 515.554.8046
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
         http://www.apteno.net

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1946745

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

1.3 Autoload?

Can someone explain to me how Propel objects are autoloaded?  I'm
using the namespace implementation on a real-world project and have
run into issues where it tells me my Peer Classes can't be found. It's
likely a bug in the namespace implementation but I'm not sure
how/where they get autoloaded.  I see Propel generating my
[projectname]-classmap.php file properly but it doesn't seem to be
getting pulled in.  Do I need to explicitly give it the location of
the classmap file?

--

-- 
Tony Bibbs
Phone: 515.554.8046
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
         http://www.apteno.net

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1861806

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

Is it safe to say reverse engineering is dead?

I'm confused.

a) Creole site makes it clear Creole is dead.
b) Propel's User Guide in build.properties section in "reverse
engineering" section says to use Creole.

Fundamentally is reverse engineering something we are supporting or
not?  I know at one point the idea was to kill Creole and spin off the
meta data stuff either into a separate project or roll it right into
Propel.

This needs to get cleaned up one way or another.  I personally feel
reverse engineering is critical for us but know I can't possible
tackle that on my own.

--

-- 
Tony Bibbs
Phone: 515.554.8046
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
         http://www.apteno.net

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1848576

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

Fwd: Moving settings from from schema.xml to property files

Fellow devs,

With the looming PHP5.3 release there is one thing yet to be cleaned
up in the Propel codebase.  As many of you know I committed namespace
support into the trunk some time ago.  You can now set the default
namespace for OM, Peer, Maps, etc.  The only thing missing is the
ability to override a namespace on a per-table basis.

My original thought was to just add a "namespace" attribute on the
<table> tag in schema.xml.  This, however, is a bit confusing when
used in conjunction with the "package" attribute which, to new Propel
users, might seem like the same thing.  My original way to fix this
was to simply deprecate the use of the "package" attribute and use
something like an "outputDIrectory" attribute instead.  In an IRC
chat with Ron, he came up with I felt was a good way to not only fix
this specific problem but to clean things up a bit: put it all in
property files.

The idea is that schema.xml would only contain meta data describing
the database.  This may not seem like a deviation from today but the
notable change in philosophy is that anything related to how
files get built or where files are outputted to would be moved to
property files. The idea then is we'd have settings like:

table.blogpost.namespace = \MyApp\Plugins\Blog
table.blogpost.outputDirectory = /path/to/MyApp/plugins/Blog/

Only draw back I see is in the case where you rename a table.  That'd
mean you'd have to touch both the schema.xml and (possibly) the
properties file.  I say possibly there because we'd have default
settings so you'd only have to specify any overrides. I think to make
this easier on Propel users we could simply give build
warnings when we find any table.foo references that don't match an
existing table.

Oh, and before we get too far, the table.foo notation above is only
for sample purposes.  How we'd structure those would, obviously, be up
for discussion. Ron and I just wanted to float this general solution
out to you all for comment.

--

-- 
Tony Bibbs
Phone: 515.554.8046
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
         http://www.apteno.net

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1749560

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

DAO for Propel with Named Query support.

Ok, I've managed to get around to polishing off a DAO implementation
for Propel.  What makes this implementation unique is it adds a
powerful alternative to Criteria in what is dubbed Named Queries.
Named Queries are nothing more than XML files containing SQL queries
that are given names.  Those names can then be used to execute a
specific query.  Why, would anybody want this?

- It's a good middle ground between portability and the desire to
prevent having to learn a new way to write queries (e.g. Criteria or
something like HQL for you Hibernate fans).
- Allows a single SQL query to be reused in multiple parts of your application.
- It keeps your application clean by taking explicit SQL calls out of your code
- Allows for quick regression testing.  Because SQL is centralized
into one (or more) files you can easily write a unit test to
regression test all your queries after a database upgrade.
- Just like Criteria it returns Propel objects OR raw data.

How does it work?

- First, all Named Query files are validated against the included XSD
- XML is compiled into a PHP array for faster, subsequent access.
- Calls to a specific query cause the query to be pulled from the
array and then ran through a PDO prepared statement.

There are two parts to this implementation:

1) Generator (optional): we add a new PEER builder class that is DAO
aware.  The only thing this builder does special is it adds a
__callStatic() method (new to PHP 5.3) that knows how to call named
queries by name (example later).  To use it simply change set the
following in your build.properties:

    propel.builder.peer.class =
propel.engine.builder.om.php5.PHP5AptenoPeerBuilder

2) DAO Implementation.  This is the guts of the implementation.  The
highlights of how to use are:

- Given this Named Query file:  http://tinyurl.com/cnd53t

You'd run a query with the following:

// Do this only once as appropriate for your application.
\Apteno\DAO\Factory::initializeDAO($this->options);

// Option #1 (preferred)
$matches = AuthorPeer::getAuthorByFirstName(array('Foo'));

// Option #2 call on DAO directly
$dao = DAOFactory::getDAO();
$matches = $dao->find('getAuthorByFirstName',array('Foo'));

I've published this work at http://pear.apteno.net and you can install
with the following (warning requires PHP 5.3 beta):

#>pear channel-discover pear.apteno.net
#>pear install pear.apteno.net/DAO

Sample code from unit tests:

http://tinyurl.com/ddot7v

I'd like to see some discussion on whether this could be added to
Propel proper or if it is better maintained separately as it is.

--

-- 
Tony Bibbs
Phone: 515.554.8046
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
         http://www.apteno.net

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1732167

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].

Creole task in 1.3?

[Fwd: UniqueValidator peer class discovery (#735)]

Relaying a post for Jarno. Tigris seems to have something against him :)

-veikko

-- 
Veikko Mäkinen
veikko <at> veikko.fi
044 5910 413
http://blog.veikko.fi

-------- Original Message --------
Subject: UniqueValidator peer class discovery (#735)
Date: Tue, 24 Mar 2009 09:17:57 +0200
From: Jarno Rantanen <jarno.rantanen <at> tkk.fi>
To: veikko <at> veikko.fi

Hi list,

I think I've stumbled on a bug in a validator, as detailed in:

http://propel.phpdb.org/trac/ticket/735

I find it peculiar that I should be the first to experience this
issue, as my setup isn't that exotic; there has got to have been
people before me using UniqueValidator and the "propel.classPrefix"
setting at the same time.  And I don't think this would go unnoticed
in any project, as it effectively stops the uniqueness validation from
ever going through.

Then again from what I hear the validators may not have received that
much testing over the years since most, if not all frameworks provide
their own, separate validation setups.

I've been having a lot of trouble sending to the list, even though I
have tried from 2 separate, properly registered accounts.  Hans
suggested registering for a tigris.org account might help, tried that,
didn't help.  I asked Veikko to kindly forward this to the list on my
behalf, until the issues with it get resolved (which I'm hoping will
be soon!).

Regards,

- Jarno

------------------------------------------------------
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=1401324

To unsubscribe from this discussion, e-mail: [dev-unsubscribe <at> propel.tigris.org].