[Serusers] register_udomain(): Invalid table version (use ser_mysql.sh reinstall)

[sip]

Heh, sorry, Greg.  It's only that particular module that I've grabbed from
OpenSER that I use in SER. 

I've used SER all along. Although, don't get me wrong, there are many
occasions where I find myself wishing that feature X was available in SER (the
ability to use AVPs in the UAC module for instance, would be immensely handy).

If you have OpenSER running, and running well, there's not really any reason
to move back to SER at the moment.  In time, that may change, as the two paths
of development are just BEGINNING to diverge more than they had in the past. 

But for now, if everything's working for you, you won't really GAIN anything
by moving to SER, and you're actually liable to lose a lot of functionality
that you may be used to. 

I chose SER originally because OpenSER was just starting out and I wasn't sure
what sort of direction it would go or what sort of support it would have if I
needed it (we use SER in a production system for quite a great many users
worldwide, so I didn't want to have a product built and then suddently find
out there was no avenue for professional support should we need to spend the
money). 

These days, it's really just a matter of preference. OpenSER releases versions
more often and has some handy features available. They're also quite good with
making documentation available. There is, however, concern among some that,
since there are more version releases, there's more a chance for instability.
SER releases versions VERY seldom and, overall, does NOT have anything
resembling good docs. It IS, however, rock solid stable in its current
release, and has many tried and true installations throughout the world using
it (SIPPhone/Gizmo project, FWD, IdeaSIP, etc). 

This isn't to say that OpenSER is ACTUALLY any less stable. It's all a matter
of perception, really. 

OpenSER and SER are NOW, however, in their more recent forms, becoming more
and more different in the basic underlying configurations. This may or may not
cause issues with migration, but it will almost certainly cause module
developers to end up having to pick sides on which code base to develop for...
and that could cause drastic differences in functionality. 

I guess only the future will tell what's in store. 

N.

N.


On Fri, 15 Sep 2006 08:48:03 -0500, Greg Fausak wrote
> Howdy N.,
> 
> I've seen your email on this list often.
> Would you mind answering a question?
> 
> You have ported from openser to ser.  Why?
> 
> I've been thinking about it, I just wonder what
> you experience was?  Does it work about the same?
> Is anything missing?  Are there features in ser that made
> it the one to use?
> 
> OK, six questions... :-)
> 
> ---greg
> 
> On Sep 15, 2006, at 6:21 AM, sip wrote:
> 
> > What's amusing is WHY this comes up. I'm not entirely sure the  
> > table check
> > code is right (or it may be correct, but it's not exactly rational).
> >
> > For instance, the a month or two ago, we were switching from using
> > lookup("aliases") to alias_db_lookup("dbaliases") as our alias  
> > check (porting
> > the code from openser to ser).
> >
> > There was a spot in the config where we'd forgotten to change the  
> > command from
> > lookup to alias_db_lookup, but had changed the table name from  
> > aliases to
> > dbaliases.
> >
> > What happens? Out pops the 'register_udomain() Invalid table  
> > version' error.
> >
> > Now, I'm not sure what it's checking for in that case, but I can  
> > tell you that
> > THAT error message (and the advice it gives to use the reinstall  
> > option of the
> > mysql script) is entirely NOT helpful. :)
> >
> > To play around, I added a version entry for dbaliases and matched  
> > its version
> > to the aliases table just to see if indeed that was the result of a  
> > version
> > check.  No dice.  What it apparently was doing was checking the  
> > format of the
> > dbaliases table against its expected format (aliases is VERY  
> > different in
> > format) and spitting out an error that the table version was  
> > incorrect. Um...
> > no... the table STRUCTURE was incorrect, but that really has  
> > nothing at all to
> > do with the version per se.
> >
> > I'm thinking that perhaps the version table with its version  
> > numbers to denote
> > some sort of extra check on the tables is, perhaps, not the best  
> > way to do
> > things. At the very least, there ought to be more applicable error  
> > messages
> > when a structure check fails. Something like "aliases table not proper
> > structure for lookup() command" would have been the most ideal  
> > error message
> > of course. I'd have known in a heartbeat where the problem was.
> >
> > Someone who DIDN'T know what he was doing might have spent all day  
> > trying to
> > install/reinstall the DB as per instructions in the error message  
> > (which don't
> > work), and would still have gotten nowhere.
> >
> >
> > N.
> >
> >
> > On Fri, 15 Sep 2006 10:48:08 +0100, bails wrote
> >> its come up before so i have to ask
> >>
> >> I have read the list archives and googled.
> >>
> >> 1. there is no reinstall option
> >> 2. there is nothing in tools/
> >>
> >> If this is in CVS why hasnt it been fixed?
> >>
> >> Bails
> >> _______________________________________________
> >> Serusers mailing list
> >> Serusers at lists.iptel.org
> >> http://lists.iptel.org/mailman/listinfo/serusers
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers