I strongly support most of these changes!

However, there are a couple modifications I would like to propose.

1) The bullet "direct users to use g_CModelFlux/g_GaapFlux_1_0 or use a signifier alias that folks will look for: g_ModelFlux" I hope is supposed to be "g_cModelFlux/g_gaapFlux_1_0 and g_modelFlux" to match the leading lower-case style proposed?
2) Unless the proposal "and if the column is in Source or ForcedSource, make it start lower case" means that some of the columns start lower-case (if in Source) and some upper-case (if not in Source)? I don't support this. I think that they should all be band_lowerCase for improved consistency (because a priori how do we know which are in Source and ForceSource without doing a separate lookup?). Ah! Looking at the before/after column list I think that the proposal is correct, but the wording in the RFC is confusing.
3) "Set the DataFrame index to the primary key which is not replicated as a column" which I read to remove the objectId column. I do not love this, as it ties us to a particular implementation of reading parquet files (via pandas). However, the unique id is still persisted as the id column if you read via another method, so these are still usable. On the other hand, I would prefer something clearly named like objectId even at the cost of redundancy.

ap_association also uses DiaSource Parquet tables (goodSeeingDiff_diaSrcTable) as input. Are these covered by this RFC? At the very least I know some of the proposed "All" changes could apply.

Yes, "all" applies to the Visit, CcdVisit, DIASource, DIAObject, ForcedSource, and ForcedSourceOnDiaObjects.  See attached notebook (that we looked at for team meeting last week) for more info. 

But this RFC only covers the DIASource and DIAObject tables that are generated during data release processing and not alert production. This means that in order for the DRP DIASource table to be consistent with the other tables output during DRP, it's schema would be inconsistent with the APDB in terms of boolean vs integer bit-packed flags

 3) "Set the DataFrame index to the primary key which is not replicated as a column" which I read to remove the objectId column. I do not love this, as it ties us to a particular implementation of reading parquet files (via pandas).  However, the unique id is still persisted as the id column if you read via another method, so these are still usable. On the other hand, I would prefer something clearly named like objectId even at the cost of redundancy. 

Look at the very end of the attached notebook for the 3 options.  I'm proposing the first option.  Continuing the same example,  If you read in the table stored with the primary key as index only in with pyarrow instead of the butler,  the diaObjectIds are still there:

>>> import pyarrow.parquet as pq 

>>> pq.read_table("file:///repo/dc2/u/yusra/dc2/DM-31825/20210919T200251Z/goodSeeingDiff_diaObjTable/3828/3/goodSeeingDiff_diaObjTable_3828_3_DC2_u_yusra_dc2_DM-31825_20210919T200251Z.parq")

pyarrow.Table

ra: double

decl: double

nDiaSources: int64

diaObjectId: int64

Edit: and to the question of what df.to_csv() says, diaObjectId is there too:

>>> df.to_csv()

'diaObjectId,ra,decl,nDiaSources\n3299854297281331201,56.645500777573766,-37.01269473596373,53\n [snip]

Oh I misunderstood. I read this as that you're dropping objectId in favor of id as the table index (which I don't like). Instead, what you're saying that objectId should be made the index column. Is this correct?

I'm not sure I understand the formatting of the notebook in this respect, though. I guess I didn't know that pandas wrote primary key columns on a different line in the header, but now that I've figured that out it makes sense.

But this RFC only covers the DIASource and DIAObject tables that are generated during data release processing and not alert production. This means that in order for the DRP DIASource table to be consistent with the other tables output during DRP, it's schema would be inconsistent with the APDB in terms of boolean vs integer bit-packed flags

Sorry, I'm not sure I follow. Assuming I've understood the notebook correctly, it cites ap_association as the source for the schema. Are you suggesting we split this, and have two different DiaSource table datasets that follow different schemas?

This proposal looks good to me and I strongly support a ccd -> detector migration because of the obvious issue that butler calls them detectors.

• Set the DataFrame index to the primary key which is not replicated as a column.
  e.g. to get objectId from the Object table, you object.index rather than object['objectId'] unless you do object.reset_index() first

Just to make sure I'm understanding: we'll still have objectId (or whichever ID column is relevant to a particular table) in the database (as opposed to Parquet) view of these tables?

Assuming I've understood the notebook correctly, it cites ap_association as the source for the schema. Are you suggesting we split this, and have two different DiaSource table datasets that follow different schemas?

Krzysztof Findeisen, For flags, I put a example implementation on ap_association which adds a config parameter that switches flags style. The answer is really that I'm suggesting whatever you want me to do.

I would especially appreciate advice on what to do with 'psFlux' -> 'psfFlux' in the Parquet DIASource Table. Should we rename it 'psfFlux' in the APDB to match? Should I leave it 'psFlux' in this parquet table for now?

Because half the comments have been confusion about how DataFrame indexes get translated to csv and parquet, here’s snippet with an example. It’s the skinniest table we have to amplify any storage differences.

To recap, I’m proposing consistency on whether the primary key column is index-only, column only, or both in all our DataFrames. Let’s cross-off column-only now. Whether “both” or “index-only” I do not care.

To summarize the questions I’ve heard so far:
1. If we do “both” does it make the Parquet table bigger on disk? Yes, it does. See attached example.
2. If we do index-only, does the key column appear in the csv and Parquet Tables as a column. Yes it does. Some background: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.to_parquet.html index parameter defaults to None, which compresses the index to a range if it is the boring default 0,1,2,3..N and stores it as a column otherwise.
3. Can I do

 parameters={"columns": ['diaObjectId', 'ra', 'decl’]} 

if it’s index-only? Yes, you can. And it gives you back the key as an index, consistent with reading in the whole parquet.

I would especially appreciate advice on what to do with 'psFlux' -> 'psfFlux' in the Parquet DIASource Table. Should we rename it 'psfFlux' in the APDB to match? Should I leave it 'psFlux' in this parquet table for now?

I suggest asking Chris Morrison [X], since he's the one who created both AP schemas.

Chris Morrison [X] explained things to me, and I have no further objections. Sorry for the disruption!

I did talk to  Chris (like you suggested) about psfFlux.  If I'm transcribing right, the conclusion was that we would ultimately like for the APDB to migrate to psfFlux as well, but that's not going to happen this week.  In the meantime, I'm going to leave the DIASource table with psFlux.  It'll be inconsistent with the other Parquet DRP tables for now. 

See notebook with the outcome of DM-31825.

https://github.com/yalsayyad/dm_notebooks/blob/master/object-table/ci_imsim_check_for_DRP_Table_and_Column.ipynb

Outcome on DIASource table:
There are arguments for keeping the DIASourceTable the similar to that in the APDB andtThe assumption that diaSourceId was a column was thoughout code I was unfamiliar with. Instead of risking breaking ap_association, I left this table as the only non-conformant in terms of:

• primary key as index-only
• psfFlux instead of psFlux