On Jan 18, 2010, at 12:31 PM, Eric Varsanyi wrote: > As I was writing another mail asking for some info on the layout of the > configuration schema this mail came in :). > > I'm trying to get my hands on the config data to try to make it portable > between systems (mostly user and phone config). sipXconfig is using a > framework called Hibernate (https://www.hibernate.org/) to persist in core > objects into SQL. There are a ton of mapping files that map classes in java > (accessed via java's introspection facilities) into tables and columns in the > SIPXCONFIG database. Any understanding of the SQL representation will come > from understanding the various live classes touched by the jetty webserver > and how they are mapped to the tables.
Also have a look at the .sql files (sipXconfig/neoconf/etc/database/*.sql) used to construct the database as well as exploring a live database using a DB browser. I like QuantumDB (http://quantum.sourceforge.net), simple to use and is an Eclipse plugin. Also be aware that a lot of objects are stored generically in the SETTINGS_VALUE table, something that is not readily apparent from examining the Hibernate mapping files. > > No specific recommendations, just what I've discovered in my quest to > understand the SIPXCONFIG schema so far. > > -Eric > > On Jan 18, 2010, at 11:09 AM, Marden P. Marshall wrote: > >> I have been looking into ways in which to improve the dissemination of >> application configuration data. Specifically to make the configuration data >> available to the application in realtime and in a granular form, as opposed >> to the current bulk delivery mechanism, i.e. configuration files. There >> were attempts in the past to do this, utilizing proprietary provisioning >> protocols running over XML-RPC, but the results fell short of the intended >> goals. So now I am looking at a simpler and more direct approach, namely, >> to have the applications access the configuration data directly, via the >> configuration database. >> >> In order to achieve the objective of realtime and granular dissemination, >> the database would utilize the postgreSQL Listen / Notify mechanism, in >> conjunction with table modification triggers. The application would then >> subscribe, i.e. Listen, for relevant database tables modification >> notifications. In response to the received notifications, the application >> would then query the database directly for the updated configuration. No >> more waiting for configuration files to be created / replicated and no more >> application restarts. >> >> How the application accesses the database records would be based upon the >> specific needs of the application and the complexity of the associated >> configuration data, but would most likely be through simple SQL queries, O/R >> mapping middleware or some combination of both. For mission critical >> applications, a local configuration cache, in the form of a properties or >> XML file, could be maintained. This would allow the application to start up >> in the absence of database connectivity, an approach that is already >> employed by some applications. >> >> Any thoughts? >> >> >> -Mardy >> >> _______________________________________________ >> sipx-dev mailing list [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev >> sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
