Re: [GSoC] Enhanced database ranges, some clarification needed.

On Tue, Apr 23, 2013 at 5:04 PM, Akash Shetye <shetyeakash@gmail.com> wrote:

> Hey again,
>
> Thanks for the reply, it really helps to know and discuss the task before
> putting in a proposal. Sorry for the quick and dirty solution, well thats
> what came to my mind right away. :P. So here is what I gather so far:
>
> *Alternating colors in database ranges "**very similar to the Format as
> Table":
> *
>
>    - Unlike MSExcel, LO has no support for Table entities. When 'Format
>    as Table' is done on a bunch of data in excel, the selected data is now
>    available as a 'Table' entity, having it's own specialized attributes like
>    row headers, total row etc and it's syntax (check 
> this<http://office.microsoft.com/en-in/excel-help/using-structured-references-with-excel-tables-HA010155686.aspx>).
>
>
>  Actually LibreOffice does already have an equivalent concept called
'Range'. See from the menu Data -> Define Range. This task would involve
expanding that existing Range feature to support formatted table like
option etc.


> *New reference syntax in formula expressions:
> *
>
>    - Currently I can enable the column label by selecting Data->Define
>    Database Range ---> click "More" and tick the column headers checkbox.
>    - We can address the entire range only currently thus =SUM(col_label)
>    is valid and supported in LO, however addressing an individual cell or a
>    range of cells within the range using col_label is not supported,
>    implementing this is what the second part is about.
>
> Well, you can disregard that =SUM(col_label) thing since that has no
relation to the database range. In fact, I'm not sure if that's supposed to
work like that...  It appears to pick up *any* string cell value even
outside database ranges. This is very weird....

Anyway, what needs to be implemented is to, given a table name and a column
label inside the table, allow formula to reference a range like
=SUM(TableName[ColLabel]), =TableName[[#Headers],[ColLabel]] and so on.

>    - Later we could try to figure an appropriate syntax, it would be
>    better to consult the devs and UX guys for that.
>
> We'll just use Excel's syntax. There is no need to reinvent the wheel
here. Doing anything different would unnecessarily introduce an
interoperability issue and there is no reason why we should use a different
syntax (rather than just being different). No UX involvement is needed
since this is just a basic formula syntax.

>    -
>
> *Demonstrating some competency in the areas relevant to the project:*
>
>    - I tried searching for bugs involving the mentioned areas, they seem
>    hard to come by. Most of those involving ScDBData are more about .xls and
>    open document incompatibilities.
>    - Perhaps you could point me to a bug or throw some keywords at me
>    which would lead me to it.
>    - Meanwhile, I have found this bug<https://bugs.freedesktop.org/show_bug.cgi?id=53920>,
>    it seems to be a little off our relevant area though.
>
> It doesn't have to be an easy hack. Technically you've already done an
easy hack, so you can just start reading the code around ScDBData, and make
some "interesting" change. I really don't care what the change is, as long
as you think the change should demonstrate your familiarity with the code,
and your competency with working with that area of the code.

Hope this helps.

Kohei