1. Lighthouse

Level 2 · A daily chart stuck at one order

The request

From Kevin Brooks, Operations Manager

“I'm planning warehouse shifts for Black Friday week and used last year's query. The chart shows a flat line at 1 order with 244 bars for one week. That can't be right. Can you fix it?”

Your goal

Fix the query. For orders placed from 2025-11-24 through 2025-11-30 (all statuses), return one row per calendar day with: order_day (a DATE), orders (number of orders that day) and completed_orders (orders with status 'completed'). Sort by order_day ascending.

  • Read from the orders tablenot done yet
  • Show exactly order_day orders completed_ordersnot done yet
  • 7 rows, sorted as askednot done yet

Your query

SQL

Loading the editor…

    ResultPreview of orders · press Run to see yours
    Preview of orders
    order_idcustomer_idorder_datestatuschannel
    10011252023-01-01 20:51:19completedweb
    10021562023-01-02 07:58:46completedweb
    1003222023-01-02 10:25:27completedmarketplace
    1004482023-01-02 11:21:51completedmarketplace

    Mote checks your result

    Press Run. Each row that matches the goal becomes a firefly in your lantern.

    Tables

    Harbor & Pine store data, ready to query.

    orders12,000 rows · 7 columns
    • order_idinteger
    • customer_idinteger
    • order_datetimestamp
    • statusvarchar
    • channelvarchar
    • shipping_feedecimal
    • coupon_codevarchar
    First 5 rows of orders
    order_idcustomer_idorder_datestatuschannelshipping_feecoupon_code
    10011252023-01-01 20:51:19completedweb0.00NULL
    10021562023-01-02 07:58:46completedweb0.00NULL
    1003222023-01-02 10:25:27completedmarketplace4.99WELCOME10
    1004482023-01-02 11:21:51completedmarketplace4.99WELCOME10
    1005822023-01-02 11:43:36completedweb0.00WELCOME10
    customers2,018 rows · 9 columns
    • customer_idinteger
    • first_namevarchar
    • last_namevarchar
    • emailvarchar
    • cityvarchar
    • statevarchar
    • signup_datedate
    • segmentvarchar
    • referral_sourcevarchar
    First 5 rows of customers
    customer_idfirst_namelast_nameemailcitystatesignup_datesegmentreferral_source
    1OwenHudsonowen.hudson@icloud.comSan FranciscoCA2022-06-02consumersearch
    2DouglasMendozadmendoza69@gmail.comAtlantaGA2022-06-02consumerNULL
    3HenryBrookshbrooks@lakesidecafe.comLos AngelesCA2022-06-04businessNULL
    4BrianGrahambgraham@bluecedarhomes.comSeattleWA2022-06-06businesspinterest
    5KyleJimenezkjimenez27@yahoo.comIndianapolisIN2022-06-07consumerNULL
    products120 rows · 8 columns
    • product_idinteger
    • namevarchar
    • categoryvarchar
    • subcategoryvarchar
    • unit_pricedecimal
    • unit_costdecimal
    • launched_ondate
    • is_activeboolean
    First 5 rows of products
    product_idnamecategorysubcategoryunit_priceunit_costlaunched_onis_active
    101Vale Velvet LoveseatFurnitureSofas1659.00NULL2023-09-11true
    102Alder Oak Coffee TableFurnitureTables919.00503.502024-05-16true
    103Orchard Rattan Dining ChairFurnitureChairs789.00429.872023-05-27true
    104Upland Oak BookcaseFurnitureStorage429.00214.702022-12-20true
    105Avery Leather Bed FrameFurnitureBeds449.00232.702021-08-31true
    order_items30,338 rows · 6 columns
    • order_item_idinteger
    • order_idinteger
    • product_idinteger
    • quantityinteger
    • unit_pricedecimal
    • discount_pctdecimal
    First 5 rows of order_items
    order_item_idorder_idproduct_idquantityunit_pricediscount_pct
    11001121931.990.00
    21001154311.990.00
    31002154411.990.00
    410021941149.000.00
    51002193219.990.00
    returns1,673 rows · 5 columns
    • return_idinteger
    • order_item_idinteger
    • returned_ondate
    • reasonvarchar
    • refund_amountdecimal
    First 5 rows of returns
    return_idorder_item_idreturned_onreasonrefund_amount
    1142023-01-10damaged83.69
    2422023-01-10wrong_item19.99
    31052023-01-14wrong_item10.99
    4242023-01-16changed_mind26.99
    51262023-01-16late20.99
    employees60 rows · 8 columns
    • employee_idinteger
    • first_namevarchar
    • last_namevarchar
    • departmentvarchar
    • titlevarchar
    • manager_idinteger
    • hire_datedate
    • salaryinteger
    First 5 rows of employees
    employee_idfirst_namelast_namedepartmenttitlemanager_idhire_datesalary
    1CatherineHaleExecutiveChief Executive OfficerNULL2016-03-01285000
    2RobertKimExecutiveChief Operating Officer12017-01-09235000
    3MeganCollinsSalesHead of Sales12018-04-16172000
    4ChloeGutierrezSalesAccount Executive32020-01-2172000
    5FrankBellSalesAccount Executive32023-05-2173000
    web_sessions40,000 rows · 7 columns
    • session_idinteger
    • customer_idinteger
    • started_attimestamp
    • devicevarchar
    • sourcevarchar
    • pages_viewedinteger
    • convertedboolean
    First 5 rows of web_sessions
    session_idcustomer_idstarted_atdevicesourcepages_viewedconverted
    1NULL2023-01-01 23:02:24mobilepaid1false
    2182023-01-01 15:07:49desktoppaid1false
    3NULL2023-01-01 16:55:46desktopdirect7false
    4NULL2023-01-01 12:43:28mobileorganic3false
    5NULL2023-01-01 13:06:21mobilesocial2false
    marketing_spend3,276 rows · 3 columns
    • spend_datedate
    • channelvarchar
    • amountdecimal
    First 5 rows of marketing_spend
    spend_datechannelamount
    2023-01-01paid492.99
    2023-01-01email37.38
    2023-01-01social200.53
    2023-01-02paid709.13
    2023-01-02email64.13

    The lesson

    The starter returns 244 rows for a seven-day window, and nearly every orders value is 1. The query is not wrong about the data. It is answering a different question: how many orders were placed at each exact second.

    Grain is set by GROUP BY, not by SELECT

    order_date is a TIMESTAMP. Two orders almost never share the same second (12,000 orders have 11,996 distinct timestamps), so GROUP BY order_date makes one group per order. The SELECT then casts each group’s timestamp to a date for display, which is why the output looks daily: 2025-11-28 appears 56 times, each with orders = 1.

    DuckDB allows this because CAST(order_date AS DATE) is a function of a grouped column. Postgres and SQL Server accept it too. Nothing warns you.

    How to spot it

    • Count the rows you expect. A week should give 7 rows. If you get 244, the grain is finer than you think.
    • Look for repeated labels. The same order_day on many rows means the real grouping key is something you are not showing.
    • Sum it back. SUM(orders) over the starter’s output is still 246, the right total. The total being right while the shape is wrong points at grouping, not filtering.

    The fix

    Group by the same expression you display:

    GROUP BY CAST(order_date AS DATE)

    DuckDB also accepts GROUP BY order_day (the alias) or GROUP BY 1. The result has 7 rows, peaking on Sunday 2025-11-30 with 58 orders, right after 56 on Black Friday and 51 on Saturday.

    Common mistakes

    • DATE_TRUNC('day', order_date) in the SELECT but the raw column in GROUP BY: same bug.
    • Adding DISTINCT to hide the repeats: you get 7 rows, each still saying 1.
    • Grouping by an extra column “just in case” (channel, status): the rows split again, at a grain nobody asked for.

    In SQL Server

    T-SQL does not accept an alias or a position in GROUP BY, so repeat the expression. CAST(x AS date) works the same way:

    SELECT CAST(order_date AS date) AS order_day, COUNT(*) AS orders
    FROM orders
    GROUP BY CAST(order_date AS date);

    On the job

    “Flat line at 1” and “the same label many times” are the two shapes of a grain bug. Interviewers like asking what one row of a result represents; answer it before you answer anything else.

    Pick what may run on this site. You can change this any time from "Cookie settings" at the bottom of every page.