quest related on latest rev

[Nightw0lf 113]

on your last quest update you should make a new ENUM type column into sql table 'character_quests' and update it CREATED, STARTED, COMPLETED with default value CREATED logic.

[Tryskell 164]

16 minutes ago, Nightw0lf said:

on your last quest update you should make a new ENUM type column into sql table 'character_quests' and update it CREATED, STARTED, COMPLETED with default value CREATED logic.

 

No, for multiple reasons :

- if core side is edited you have to edit it here aswell (making 2 places to edit).

- while it's simple to manage with few entries and one or two enums, it becomes a burden to maintain when you got 5-10 enums with xx choices (case of characters table).

- ENUM implementation can evolve / differ from one db type to another (for exemple, ENUM doesn't exist in SQLSERVER).

- strictly no L2J forks use that consistantly, making it a questionable choice.

[Nightw0lf 113]

i believe edits and maintain is not the main problem, but i taking the example of characters into consideration for future could be an example to avoid, but since server/client side wont be evolving anytime soon the only thing needs maintenance will be future sql storage updates, about sqlserver you might know better (in my opinion should not be taken into consideration) finally its up to developers perspective so its respectable.

 

[Rootware 113]

1 hour ago, Nightw0lf said:

on your last quest update you should make a new ENUM type column into sql table 'character_quests' and update it CREATED, STARTED, COMPLETED with default value CREATED logic.

 

There is no ENUM as you might think. Database contains the string values of "ENUM names" instead abstract digital values before. All strings can be easily interpreted in ENUM and back again if necessary. It's good developing practice and more readable if need make some changes or check something. Even L2OFF uses this trick.

[Nightw0lf 113]

13 hours ago, Rootware said:

 

There is no ENUM as you might think. Database contains the string values of "ENUM names" instead abstract digital values before. All strings can be easily interpreted in ENUM and back again if necessary. It's good developing practice and more readable if need make some changes or check something. Even L2OFF uses this trick.

you are like a living wiki :D i mostly got covered by tryskel's answer but for example it would be better for me as i imagine if i'd use acis to check a quest or something else's state on navicat by viewing directly a column with state COMPLETED thats why i posted, thanks for the info tho, i am using on other projects that way of thinking and your info is good for me

[SweeTs 193]

On 11/13/2020 at 10:08 AM, Nightw0lf said:

by viewing directly a column with state COMPLETED

Obviously storing a string/enum on table column is "readable on first glance", BUT what if you actually edit core side and change COMPLETED into COMPLETE (or opposite).

 

What will happen? Shit will happen. 💩

 

Normally, you would / should have 2 tables, one storing the "enums" (key, value) and desired column, should hold the key (id). Soo, whenever you change the value, you are safe and won't face any problems.

 

Sure, you can have enums on core side, only, but that way when you execute manual SQL query, you won't know what means 1/2/3. With linked tables, you simply read from that table and voila, yet you have to write longer queries to find out what is what, but hey.. That's how it works 😅