Hey sorry for the late reply.
I meant to say can you list down exactly what it can return? “Up”/“Down”/“Running”/“Unknown” etc., and what these states will mean?
“dynamic library will have the functionality for the PBS server to access the database”
Just checking, is server the only daemon that write to the db? mom also has job_save() calls, so i thought ill ask.
“PBS_DB_CONNECT_STATE_NOT_CONNECTED” that’s quite long, how about replacing “CONNECT_STATE” with just “CONN” ? so this one will become PBS_DB_CONN_NOT_CONNECTED?
“PBS_DB_DOWN”, “PBS_DB_STARTING”, “PBS_DB_STARTED”: “down” and “started” don’t go together, please make it “up” and “down”, or “started” and “ended”
“pbs_db_mominfo_time_t *pbs_db_mominfo_tm”: how about making this a pbs_db_mom_info_t instead? that’ll make it consistent with the other object types.
pbs_db_job_info:
“ji_svrflags;”: what is this?
“ji_un_type”: please rename this to be more intuitive
ji_momaddr; host addr of Server: the var name says momaddr but comment says addr of server? if it’s mom addr, what will this be if the job runs on multiple moms?
ji_rteretry;: what is this?
"char ji_4jid[8]; /* extended job save data */
** char ji_4ash[8]; /* extended job save data */
Can these be combined into one?
pbs_db_svr_info
:
sv_jobidnumber
: will this be useful after multi-server?
pbs_db_sched_info
:
Would a ’ partition_name
field make sense here? now that scheds can only serve one partition, it might speed up db queries to find the sched associated with a partition if we add a field for it here. What do you think? Similarly, it might be useful to add a parititon_name field to queue and node info structures.
pbs_db_query_options_t: Will this make sense for a no SQL db ?
" query_cb_t: Function pointer for call back function to process the data returned by the database."
That seems like a weird name for a function pointer, how about just calling it “query_cb” ? Can you also mention what kind of “processing” is this function intended for? (as opposed to the kind of processing that the Server might do after querying data from db)
“PBS_DB_MOMINFO_TIME”: Again, this sticks out, I think we should just call it PBS_DB_MOM
under pbs_db_save_obj():
1 - Execution of prepared statement failed.
0 - Success and > 0 rows were affected.
1 - Execution succeeded but the statement did not affect any rows.
did you mean -1 for one of them? Same comment for other interfaces as well.
int pbs_db_load_obj(pbs_db_conn_t *conn, pbs_db_obj_info_t *obj)
int pbs_db_find_obj(pbs_db_conn_t *conn, pbs_db_obj_info_t *obj, pbs_db_query_options_t *opts, query_cb_t query_cb)
shouldn’t ‘obj’ be a double pointer in these functions?
Under pbs_db_del_attr_obj:
" Returns: Error code
0 - Success
1 - On Failure"
Will it return an error code or 0/1? I don’t think it can return both, it’ll be confusing to the callers.
pbs_db_start, pbs_shutdown_db and pbs_status_db: Don’t we need char *pbs_ds_host and int pbs_ds_port here? or a connection handler for shutdown and status?