1 Commits (8fccfc74e2359140f01a42588609ae83264c21bf)

Author	SHA1	Message	Date
Rene Krenn	719fd2750b	TT#36660 new billing mappings tables, procedures, views ... to optimize the heavyweight fraud events query (and similar places), the billing.billing_mappings is refactored into 2 new tables that will hold a scan-line rendered representation of the former billing_mapping records known with their (nullable) start and (nullable) stop cols. accessing this new tables (eg. insert a billing mapping to switch a contract's billing_profile, or query for the contracts current billing profile) is not supposed to be done explicitly, but by the stored sql proc provided: - "billing.create_contract_billing_profile_network_from_package": set/add a bunch of profiles from a profile package at once. - "billing.get_billing_profile_by_*": get a contract's billing profile id at the given epoch. + by_contract_id: customer or system contract id + by_uuid: subscriber uuid + by_peer_host_id: peer server id - "billing.get_billing_profile_by_*_network": get a contract's billing profile id for the given IPv4 or IPv6 string at the given epoch. + by_contract_id: customer or system contract id + by_uuid: subscriber uuid + by_peer_host_id: peer server id The enhanced fraud queries can finally make use of a view that can be used to get the current billing profile id: - "billing.v_actual_billing_profiles": View showing all contracts' billing_profile_id at the current time. In contrast to the procs, the view can be used nicely in joins of stmts. 15418.up also cover copying+transforming the existing records in billing.billing_mappings. the old table and records are left for now but are subject to be dropped soon. if new contracts were created during the upgrade (although discouraged), the transformation of not yet transformed contracts can be done by simply re-executing call billing.transform_billing_mappings(); Change-Id: Ib5ddd620b2b08ed7db4b6448a44931d37ea5b06a	7 years ago