ok i see your point, but.... should we generate it differently depending on column type? dodnt you think doctrine's power comes in great measures from the facts that it does _not_ generate redundant code like propel? anyway, i think that thoose ugly static methods in sfDoctrineRecord should not stay there.
2007/9/6, Lukas Kahwe Smith <[EMAIL PROTECTED]>: > > > Hartym wrote: > > > User: > > tableName: account > > templates: [ timestamp ] > > columns: > > login: string(20) > > password: string(20) > > > > Which would automagically add created_at and updated_at fields, and add > > them a listener for onPreInsert and onPreUpdate events. > > > > I'd like to have some feedback on this, as it breaks some B/C, but > > removes big limits in overriding possibilities (fun how that's propel > > anti BC-break hacks that bring such limitations), and adds some great > > new features of doctrine into sfDoctrineSchema. > > I do not think this is the way to go for this thing. It might be nice to > be able to set a different base class, but for this particular feature I > think the preInsert() and preUpdate() methods should simply be generated > into the base classes directly, depending on if a created_at and/or > updated_at field exists. Notice the "or", in same cases I only want > either of the fields. > > regards, > Lukas > > > > -- Best regards Romain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
