Ad
  • Default User Avatar

    It would be nice to have some sample tests.

  • Default User Avatar

    Questionable statement about performance and memory consumption.
    In postgres WITH is always optimization fence. PG always materialize it.
    Here you basically told PG to make two temp tables out of payment table doing two scans (index or maybe full table ones as we don't have any idea if staff_id is indexed or not or anything about its cardinality and distribution).
    Sorry, but with all things being equal this query does two scans instead of one while AGGREGATE WITH FILTER approach gets all aggregates in a single pass over the table (using index or not). Not knowing table statistics we cannot simply say what will be faster.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    expected: [{:location=>"US", :id=>1, :name=>"Awesome Rubber Bottle", :price=>50.07, :card_name=>"Toni Senger II...ber=>"1234-2121-1221-1211", :transaction_date=>#<Date: 2012-07-29 ((2456138j,0s,0n),+0s,2299161j)>}]
    got: [{:location=>"US", :id=>1, :name=>"Awesome Rubber Bottle", :price=>50.07, :card_name=>"Toni Senger II...ber=>"1234-2121-1221-1211", :transaction_date=>#<Date: 2016-07-24 ((2457594j,0s,0n),+0s,2299161j)>}]

    That is the problem. We get 1 failure while submitting. There is no requirement for order by and I have tried both ASC and DESC, I get a different failure each time. Many of these US/EU sales based DB problems are poorly specified. There are hidden ordering requirements every where.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This is still confusing.

    Order by US then EU just means show the US orders first. The requirement needs to state to show them ordered by ID, US first then EU.

  • Custom User Avatar

    No, even as a native speaker it is quite vague. The wikipedia article helps a little but is still not clear.

  • Custom User Avatar

    That's true, but anyone who's read LYAH should be familiar with monoids, especially 6-kyu Haskellers, the kata's difficulty level.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    A fair point, but I'm sure people are clear as to what I'm meaning.

  • Default User Avatar

    Err..Sorry I was speaking about the haskell version.

    the [a] datatype in haskell is called a list (because it /is/ a linked list).

    There are arrays in Data.Array and its sub modules.

  • Default User Avatar

    Even a stub of tests would be nice.

  • Default User Avatar
  • Default User Avatar

    For clarity in dicussion. The following is the list in, the tree created, and the tree by levels result. Either buildTree needs to be fixed or the expectation that treeByLevels is the inverse of buildTree needs to change.

    testIn = [2, 8, 9, 1, 3, 4, 5] -- becomes the following tree
    testTree = Just (TreeNode (Just (TreeNode (Just (TreeNode Nothing Nothing 9))
                                              (Just (TreeNode Nothing Nothing 1)) 8))
                              (Just (TreeNode (Just (TreeNode Nothing Nothing 4))
                                              (Just (TreeNode Nothing Nothing 5)) 3)) 2)
    -- which, by levels is
    byLevelsResult = [2,8,3,9,1,4,5]
    
  • Loading more items...