headers
Ron Rademaker | 5 May 2008 16:16
Picon

Re: Propel event handler

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Hans Lellelid | 5 May 2008 18:53

Re: Propel event handler

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).

Hans

On Mon, 05 May 2008 16:16:33 +0200, Ron Rademaker
<r.rademaker <at> virtualbuilding.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
(Continue reading)

Permalink | Reply | 7 comments |
headers
alexk400 | 6 May 2008 06:00
Picon
Favicon

I need a User Object based on custom SQL


I want the user object to be any select sql and it works based select sql ,
delete sql , update sql statement , count select statment. 

You may ask create your own.. but i want to be consitent with rest of my
propel data access. It looks like another table object but internally it
handles all complexities. It should also have all criteria just like other
propel objects. 

User data for the object :

1. select sql
2. delete sql
3. update sql
4. count select
6 Tables involved.

if it is already there , just let me know how to achieve it. Yes it may not
be portable , hey it will help big time for custom processing.

Advance Thanks!!!!!! 
:jumping:

--

-- 
View this message in context: http://www.nabble.com/I-need-a-User-Object-based-on-custom-SQL-tp17071556p17071556.html
Sent from the propel - dev mailing list archive at Nabble.com.
Permalink | Reply | 8 comments |
headers
alexk400 | 6 May 2008 06:05
Picon
Favicon

Re: I need a User Object based on custom SQL


Those information can be provided in a config file.

[Userobjects]

[ordersbycutomerswithshipping]
[tables]=order,customer,shipping
[selectsql]=
[countselect sql]=
[updatesql]=
[deletesql]=

In that way i will have one code base for all kind of complex database
queries....

Tell me we can do that already...that would be super awsome!.
--

-- 
View this message in context: http://www.nabble.com/I-need-a-User-Object-based-on-custom-SQL-tp17071556p17071560.html
Sent from the propel - dev mailing list archive at Nabble.com.
Permalink | Reply | 1 comment |
headers
Ron Rademaker | 6 May 2008 09:15
Picon

Re: Propel event handler

Hi Hans,

I totally agree on getting 1.3 out. What tickets are currently blocking 
a RC?
I'm going to do some more testing on the event stuff today and if 
everything goes well, I'll check it into trunk.

Ron

Hans Lellelid wrote:
> 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).
>
> Hans
>
>
Permalink | Reply | 6 comments |
headers
Hans Lellelid | 6 May 2008 15:39

Re: Propel event handler

The one ticket I would really like to fix before RC is
http://propel.phpdb.org/trac/ticket/606

If you have a few spare minutes and want to look at that, I'd appreciate
it! -- Otherwise, that's first on my list to fix and I should be able to
finally get some non-housework done this weekend :)

Hans

On Tue, 06 May 2008 09:15:41 +0200, Ron Rademaker
<r.rademaker <at> virtualbuilding.nl> wrote:
> Hi Hans,
> 
> I totally agree on getting 1.3 out. What tickets are currently blocking
> a RC?
> I'm going to do some more testing on the event stuff today and if
> everything goes well, I'll check it into trunk.
> 
> Ron
> 
> Hans Lellelid wrote:
>> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ron Rademaker | 6 May 2008 15:47
Picon

Re: Propel event handler

I just looked at that ticket. If I understand the problem correctly 
extending the addJoin API so it also accepts arrays for the first two 
arguments would solve it. 
Like:$criteria->addJoin(LoggedOfferIPPeer::MEMBER_ID, 
LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);

$criteria->addJoin(LoggedOfferIPPeer::OFFER_ID, LoggedOfferPeer::OFFERID, Criteria::LEFT_JOIN);

Hans Lellelid wrote:
> The one ticket I would really like to fix before RC is
> http://propel.phpdb.org/trac/ticket/606
>
> If you have a few spare minutes and want to look at that, I'd appreciate
> it! -- Otherwise, that's first on my list to fix and I should be able to
> finally get some non-housework done this weekend :)
>
> Hans
>
Permalink | Reply | 4 comments |
headers
Ron Rademaker | 6 May 2008 15:50
Picon

Re: Propel event handler

Ok, really nice that CTRL+enter in thunderbird sends mail :)

Let's try again:

I just looked at that ticket. If I understand the problem correctly 
extending the addJoin API so it also accepts arrays for the first two 
arguments would solve it. 
Like:

$criteria->addJoin(LoggedOfferIPPeer::MEMBER_ID, LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
$criteria->addJoin(LoggedOfferIPPeer::OFFER_ID, LoggedOfferPeer::OFFERID, Criteria::LEFT_JOIN);

becomes:

$criteria->addJoin(array(LoggedOfferIPPeer::MEMBER_ID, LoggedOfferIPPeer::OFFER_ID),
array(LoggedOfferPeer::MEMBER, LoggedOfferPeer::OFFERID), Criteria::LEFT_JOIN);

Which would result in SQL like:

SELECT offer_ip_log.MEMBER_ID, offer_ip_log.OFFER_ID,
       offer_ip_log.IP, offer_ip_log.TIME, offer_ip_log.EXPIRED 
  FROM `offer_ip_log`
  LEFT JOIN offerhistory ON (offer_ip_log.MEMBER_ID=offerhistory.MEMBER and offer_ip_log.OFFER_ID=offerhistory.OFFERID)

Of course the old API will have to keep working as well.

Is this right? I'll take a look at implementing this, but I don't expect any problems.

Ron
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Lellelid | 6 May 2008 15:49

Re: Propel event handler

Is that true ... ?  Maybe; I thought we'd have to have them be separate
joins, but I haven't looked at this recently.  I was assuming that we'd
need to introduce some aliasing to avoid collision in the generated
doSelectJoin*() method.

Hans

On Tue, 06 May 2008 15:47:08 +0200, Ron Rademaker
<r.rademaker <at> virtualbuilding.nl> wrote:
> I just looked at that ticket. If I understand the problem correctly
> extending the addJoin API so it also accepts arrays for the first two
> arguments would solve it.
> Like:$criteria->addJoin(LoggedOfferIPPeer::MEMBER_ID,
> LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
> 
> $criteria->addJoin(LoggedOfferIPPeer::OFFER_ID, LoggedOfferPeer::OFFERID,
> Criteria::LEFT_JOIN);
> 
> 
> 
> 
> Hans Lellelid wrote:
>> The one ticket I would really like to fix before RC is
>> http://propel.phpdb.org/trac/ticket/606
>>
>> If you have a few spare minutes and want to look at that, I'd appreciate
>> it! -- Otherwise, that's first on my list to fix and I should be able to
>> finally get some non-housework done this weekend :)
>>
>> Hans
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ron Rademaker | 6 May 2008 17:51
Picon

Re: Propel event handler

Hi Hans,

I just commited a fix for 606. At least it works for the unit test you 
added and those I added earlier today.

Ron

Hans Lellelid wrote:
> Is that true ... ?  Maybe; I thought we'd have to have them be separate
> joins, but I haven't looked at this recently.  I was assuming that we'd
> need to introduce some aliasing to avoid collision in the generated
> doSelectJoin*() method.
>
> Hans
>
> On Tue, 06 May 2008 15:47:08 +0200, Ron Rademaker
> <r.rademaker <at> virtualbuilding.nl> wrote:
>   
>> I just looked at that ticket. If I understand the problem correctly
>> extending the addJoin API so it also accepts arrays for the first two
>> arguments would solve it.
>> Like:$criteria->addJoin(LoggedOfferIPPeer::MEMBER_ID,
>> LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
>>
>> $criteria->addJoin(LoggedOfferIPPeer::OFFER_ID, LoggedOfferPeer::OFFERID,
>> Criteria::LEFT_JOIN);
>>
>>
>>
>>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane