phraseid numbers ..... big problem! ... i warned that this would happen!

[Paul M]

Originally Posted by trafix

as far as i am aware ..... it is coded into vb to ignore phraseids above 1000 ... whick narrows it down from 65,000 odd

Is it ? I wonder why ......

Oh well, the installation script could just run a query to find the largest current typeid, and add 1 ......

[Floris]

Originally Posted by Paul M

Is it ? I wonder why ......

Oh well, the installation script could just run a query to find the largest current typeid, and add 1 ......

I wouldn't know .. but I think its simply a limitation of field storage in mysql ?

[Xenon]

hmm, i wonder why phrasetypid doesn't have the autoincrement.

Did the devs just forgot it?
or has it a reason, would be nice to know

[Paul M]

Originally Posted by floris

I wouldn't know .. but I think its simply a limitation of field storage in mysql ?

As I said above, the field [in the mysql table] is an unsigned smallint, so it can range from 0 to 65535, trafix seems to imply the limitation has been coded into vB for some reason. I haven't checked it, just taken his word as correct.

[trafix]

well actually im not sure how it works but spacial phrase groups use id nos above 100 for ex
email body = 2000
email subject = 3000
something else uses 9000

but they are all multiples of 1000

and what about all the phrase ids that are currently scattered between where vb stops and 1000 i have used
153 for the members choice ... i will have to change it
888 for the jukebox .... i dont know if anyone else is using it
152 for the trader .... i dont know if anyone else is using it

there again if i change the idno for the members choice ... i have to code the installer to check which one is used before updates can be made

[trafix]

Originally Posted by Xenon

hmm, i wonder why phrasetypid doesn't have the autoincrement.

Did the devs just forgot it?
or has it a reason, would be nice to know

i think its delibrate as the phraseid have to be identical in both tables

[Marco van Herwaarden]

Well the phrasetypeid is a real problem with the way hacks are made right now, but this could be solved with some intelligent installer. The question is however, do we want that for 1 hack different phrasetypeid's will be used on every installation. That don't make life easier.

About the permission bitfields, i really think this is a much bigger problem. These normal require manual file edit's, where you must manually check in the sources if a wanted number is still free, and if not decide on a new number. With deciding on a new number it is very easy for a non-coder who don't have god knowledge about how bitfields work, to choose the "wrong" number.

I think it would be a great improvement to hacks released for vB (and thus an improvement of the experience users have with vB) if coders can make good agreements on this, and that jelsoft will support this with a registration system of used id's.

[Revan]

Originally Posted by trafix

oops both

you need to add the row to the phrasetypeid table and then phrases to the phrase table

i spose you could add it the phrasetypeid with null .... but then you would have to quiry what phrase id was allocated then use a string to add the phrases ...

...Either that, or we could use $DB_site->insert_id();

[Dean C]

Just make a function to check if the phraseid/phrasegroupid is available. Then if it's not try another one. It's not hard This was done with vB2 hacks and the setting/settingroup table

[Marco van Herwaarden]

Originally Posted by Dean C

As I said in the other thread too, just code it into your installers to check what settingid's are available and then just insert them with that ID. It's not rocket science and used to be done on many installers in vB2

And how to handle the permission bitfields then? Not in this way. Maybe we can find a way if we make good agreements among hack developers.