Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2008-05-05 09:53:00 PDT
Message Hi Ron,

If you'd like to merge in 1.3 changes to trunk, you could commit it there.
I don't *think* there's anything in trunk that's not in 1.3, so you could
also delete trunk and copy 1.3. I'd rather not add new features to 1.3 for
now, because releasing that version is highest on my priority list (as soon
as I've finished "moving in" to my new house).


On Mon, 05 May 2008 16:16:33 +0200, Ron Rademaker
<r.rademaker@virt​ualbuilding.nl> wrote:
> Hi all,
> I picked up on the mail below again (which I've send to the list last
> November) last week and today. I actually got the first handler (which
> creates backups when changing db records) working in a very limited
> test. I don't think it would be a good idea to commit this to 1.3
> because I expect this first version to still be quite buggy (and getting
> 1.3 into RC would be nice) . However, from the looks of it trunk is
> pretty old right now (and the event handler thing requires the commit I
> did this morning) and nobody probably uses trunk so it wouldn't get
> tested anyway. Where should I commit this stuff?
> Ron
> Ron Rademaker wrote:
>> Hi all,
>> Last week I told you about my idea to create a backup function in
>> propel based on sql triggers. I've been working on this a bit this
>> week only to find out sql triggers and procedures have some very
>> annoying properties. This would result in having to redefine all
>> triggers whenever you change your schema, and often no errors if you
>> forget to do this (and I *know* I would something forget it and I
>> would be *very* surprised if the other developers here wouldn't). I
>> don't think this is a good idea so I've come up with a different, much
>> more flexible, database independent solution. The only drawback I see
>> is that performance would be better if the backup functionality was
>> implemented in sql.
>> The basic idea is that you can add event to tables and columns (and
>> databases, though I haven't though of a useful example for that yet).
>> An example schema (I think the first event is obvious, I'll explain
>> the second later) could be:
>> <table name='foo'>
>> <column name='id' primaryKey='true' type='INTEGER'
>> autoIncrement='true'/>
>> <column name='date' type='TIMESTAMP'/>
>> <column name='bar' type='VARCHAR'/>
>> <event occasion='onChange'> <!-- this is now defined on the table,
>> but could also be defined on the bar column -->
>> <handler name='setcolumn'>
>> <parameter name='column' value='date'/>
>> <parameter name='value' type='phpfunction'>
>> <function name='date'>
>> <parameter value='"now"'/>
>> </function>
>> </parameter>
>> </handler>
>> </event>
>> <event occasion='onCreate'>
>> <handler name='saver' function='registerSave'/>
>> </event>
>> <event occasion='onSave'>
>> <handler name='saver' function='triggerSave'/>
>> </event>
>> </table>
>> <table name='bar'>
>> <column name='id' primaryKey='true' type='INTEGER'
>> autoIncrement='true'/>
>> <column name='bar' type='VARCHAR'/>
>> <event occasion='onCreate'>
>> <handler name='saver' function='registerSave'/>
>> </event>
>> <event occasion='onSave'>
>> <handler name='saver' function='triggerSave'/>
>> </event>
>> </table>
>> Both table foo and bar have the saver handler for the onCreate and
>> onSave event. I intent to implement the event / handler structure
>> using the observer pattern, Propel objects being Observables and event
>> handlers being Observers. The saver handler (observer) would be an
>> example where the onCreate event registers the propel object with the
>> handler and the onSave triggers save on all registered objects. This
>> way you can save multiple objects with a single save() call,
>> potentially this means you could tweak things so that you would add or
>> update many objects in a single sql query.
>> I know many of the things this will make possible are already possible
>> by overriding functions in the propel classes. I do believe however,
>> that this mechanism would prove to be very flexible and easier to
>> maintain than implementations in propel classes (I still have a whole
>> lot of classes where I need to change save(PDO $con = nul) to
>> save(PropelPDO $con = null)).
>> I'll be starting to build this shortly, anyone having suggestions,
>> improvements, seeing upfront bottlenecks, just let me know and if I
>> think it makes sense I'll try to do something useful with it ;)
>> Ron
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org