Instead of ejabberd.sql,I am using a custom MySQL schema(because of legacy reasons).
I will be doing some DB operations on certain activities like Ping,Pong,Msg deliverd,Msg read and most importantly getting/setting roster list and announcing presence(all of these on my own schema).
However,ejabberd seems to use ejabberd.sql all throughout and its source code is pretty much dependent on it.Fiddling with the source code is the last thing I would do since I am not aware of its dependencies.
Possible ideas :
Lets say if I extend ejabberd by writing my own modules,then what use will mod_roster_odbc be?I simply dont want to loose on all functionality of ejabberd but I have no other option than using custom schema here.
OR
Do I need to modify each and every query in odbc_queries and ejabberd_odbc.If there is a certain centralized module which can allow me to modify queries,reflecting it everywhere without disturbing the harmony of ejabberd,it would be great.
All in all,I want to avoid tackling dependencies and getting my work done in smartest way possible.But I am pretty vague about what the best approach might be?
EDIT Changing this answer after learning more about the OP's situation.
The use-case you have in mind calls for strong separation between your core business data and the chat service. Chat must be thought of as an external service, not something integral to the overall system (even if it is a "core" service from a user perspective, chat should never be hard-wired into, say, account management).
Use the existing infrastructure as a place where authentication takes place, and set chat up using ejabberd independently and configure it to make external authentication calls to your core service.
If you require persistence or inclusion of your legacy chat data, you can import it to the ejabberd schema (not so great), or leave the legacy chat system in "read only mode" and make all new chat go through ejabberd (better, especially if you take the time to make the interface seamless to users). If you need the legacy data for analytical purposes, then you should export it to an analytics schema and extract (batched, clumsy) or reflect (live, much better) the ejabberd data to the same schema for analysis.
Whatever you do, don't burden the core system with chat duties, and don't burden the chat system with analytical duties. These are things that should be strongly independent, even running on different hardware if your system is either very large or has significant robustness requirements (and your budget fits).