[Ethereum] Large contract (bytecode >= 45K) causes out-of-gas on deploy

Is this the failing transaction? https://testnet.etherscan.io/tx/0x369c48423586f5cdffefb2d202d6588e3874b6f1075b3feda205c7718f13dff3

This shows you sending only 78525 gas, which is probably not enough to call your getPairPrice() function, which in turn needs to pay for some initial oraclize functions - I think it'll be a price lookup and an event write, and possibly some storage.

The gas parameter you're adding to oraclize_query() isn't for your call to getPairPrice(), it's for the call that Oraclize will make later to your __callback() function. That will be done in a separate transaction, and that part will need to come out of the value that gets transferred from your contract balance when you send oraclize_query(), not the gas that you send to getPairPrice().

Here's a simple hub (Bakery) that deploys contracts (Cookie) from a template and keeps track of the contracts created.

Note that Cookie is part of the source file so Bakery can "see it" during compilation. Cookie's ByteCode will become part of Bakery so the new Cookie() invocation knows what to do.

Deploy the hub/factory (Bakery). It's not necessary to deploy the template (Cookie). You can create as many of the latter as needed by calling a function in the former.

pragma solidity ^0.4.8;

contract Bakery {

  // index of created contracts

  address[] public contracts;

  // useful to know the row count in contracts index

  function getContractCount() 
    public
    constant
    returns(uint contractCount)
  {
    return contracts.length;
  }

  // deploy a new contract

  function newCookie()
    public
    returns(address newContract)
  {
    Cookie c = new Cookie();
    contracts.push(c);
    return c;
  }
}


contract Cookie {

  // suppose the deployed contract has a purpose

  function getFlavor()
    public
    constant
    returns (string flavor)
  {
    return "mmm ... chocolate chip";
  }    
}

If you need more functionality in the index (e.g. is 0x123 a contract?) consider more feature-complete storage patterns: Are there well-solved and simple storage patterns for Solidity?

Hope it helps.