"Jorge Vargas" <[EMAIL PROTECTED]> writes: > On 10/23/06, Jorge Godoy <[EMAIL PROTECTED]> wrote: >> >> >> Gentlemen, >> >> please, lets be more careful with commits on the *stable* branch. I don't >> think that changing the identity code like it was done is right since there >> are some differences between the model that was used and the one available at >> model.py, specially with regards to table names. > I'm sorry I should had check if those models where different. they are > not supposed to > > is there anything different then the table name?
Yes. There are different fields on model.py and in the class you "removed" from the code. Check the code in turbogears.visit.sovisit.TG_Visit and at the model in a quickstarted project. http://trac.turbogears.org/turbogears/browser/branches/1.0/turbogears/visit/sovisit.py#L81 and http://trac.turbogears.org/turbogears/browser/branches/1.0/turbogears/qstemplates/quickstart/%2Bpackage%2B/model.py_tmpl?rev=1978#L32 Check that there's "Visit" and "VisitIdentity" and in old code there was even another differente where the name for VisitIdentity's table was 'tg_visit_identity' and not the default name supplied by SQL Object (and I believe that in a prior discussion it was agreed that the prefix 'tg_' was a good thing to have and to keep since it allowed the project to use similar names without clashing with TG's support tables). > actually this fix a bug that I think your code was depending on that > was introduced in > > http://trac.turbogears.org/turbogears/changeset/1604#file12 I found this bug because after the update I couldn't log into the system. This was an identity failure, not on my code. So I believe this was a bug in identity. It hadn't reached my code yet. > as you can see Kevin moved the sovisit code to check for a config > entry and added the Visit table to model.py I saw that. > but didn't changed the variable so people changing their visit class > in model.py where not getting anything out of it. I know. But there were these differences that aren't clear enough in a *stable* migration path. If it was in the trunk, I'd think that this was a good change, but in a stable branch I believe it will cause some harm. > Anyway I'm sorry I didn't knew you where running out of a 1.0 co I'll > be more careful. That's the only way I found where I could intensively test new features. I'm glad I got this now and not after releasing something new. So, we have to check this migration path and document the necessary changes for projects quickstarted with 0.9.x / 1.0b1 to what will be the next 1.0 release. The rant was not because I'm running from 1.0, but because this change messed with more things than it should without some big warning and/or migration path. Providing the information on how to upgrade looks like the best fix to me. -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
