On 10/23/06, Jorge Godoy <[EMAIL PROTECTED]> wrote: > > "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. > ok I must be blind other then the class and table names I see them identical
> 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 > aren't those 2 the snip I pasted? > > 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. I believe what happen here is that before you upgraded identity loaded both your tg_visit and visit ttables then set the visit table as default BUT keep using the tg_visit, after the upgrade since now it goes to the table it should (the one specified in the config) it's going to the visit table which is empty! together with the visit_identity table. > 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. > comment out the line that uses the model.py classes? > > 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. > that's a good idea. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
