| 22 | | To-do's: |
| 23 | | |
| 24 | | * Add logging (so we can see what going on when it crashes in production environment, if it ever occurs) |
| 25 | | * Add Thread Monitor |
| 26 | | * How to handle/load/implement descriptive tables like LAB_BEPALING, this table is actually big list of Measurements with a lot of extra fields. |
| 27 | | * options: |
| 28 | | * Create a new type that extends Measurement and hold the additional fields |
| 29 | | * Merge data into the label of Category |
| 30 | | * How to handle/load/implement the table that describes which foreign keys are used between the tables. |
| 31 | | * The matrix viewer should know this info as well to build correct queries |
| 32 | | * Re-factor lifelines packages (it a little bit messy), remove old not used code anymore and place in descriptive packages |
| 33 | | * Remove JPA dependencies |
| 34 | | * Many-to-many in JPA are not working properly with Labels, for example ov.setTarget_Name("x"). In JDBCMapper this is solved, but know not where and how we could best do this for JPA. This set by label should also be put into generated test |
| 35 | | * Remove change org.molgenis.!JpaDatabase interface to prevent this |
| 36 | | * //trick to prevent compilation problem in Hudson, should be changed! |
| 37 | | * this.em = ((!JpaDatabase)db).getEntityManager().getEntityManagerFactory().createEntityManager(); |
| 38 | | * Jpa reverse relation cause hudson to give compile error. Should be added to molgenis for non-jpa entities. And implement as @deprecated of throw unsupportedOperationException. |
| 39 | | * Update CSV readers to be multi threaded? |
| 40 | | * In (production) environment it's not a bad idea to put the java executable in the Oracle VM that part of the database. |
| 41 | | * Last but not least, Test if data is loaded correctly (Test from Anco). |
| 42 | | * We should make sure that the data is always loaded into the right format (this means that it always end up the right way in database). |
| | 22 | To-do's / issues: |
| | 23 | * Dates |
| | 24 | * BEZOEK_ID (PK?) empty in LL_VW_BEZOEK |
| | 25 | * The data in the Test and Acceptation environments are not the same |
| | 26 | * Add logging (so we can see what going on when it crashes in production environment, if it ever occurs) |
| | 27 | * Add Thread Monitor |
| | 28 | * How to handle/load/implement descriptive tables like LAB_BEPALING, this table is actually big list of Measurements with a lot of extra fields. |
| | 29 | * options: |
| | 30 | * Create a new type that extends Measurement and hold the additional fields |
| | 31 | * Merge data into the label of Category |
| | 32 | * How to handle/load/implement the table that describes which foreign keys are used between the tables. |
| | 33 | * The matrix viewer should know this info as well to build correct queries |
| | 34 | * Re-factor lifelines packages (it a little bit messy), remove old not used code anymore and place in descriptive packages |
| | 35 | * Remove JPA dependencies |
| | 36 | * Many-to-many in JPA are not working properly with Labels, for example ov.setTarget_Name("x"). In JDBCMapper this is solved, but know not where and how we could best do this for JPA. This set by label should also be put into generated test |
| | 37 | * Remove change org.molgenis.!JpaDatabase interface to prevent this |
| | 38 | * //trick to prevent compilation problem in Hudson, should be changed! |
| | 39 | * this.em = ((!JpaDatabase)db).getEntityManager().getEntityManagerFactory().createEntityManager(); |
| | 40 | * Jpa reverse relation cause hudson to give compile error. Should be added to molgenis for non-jpa entities. And implement as @deprecated of throw unsupportedOperationException. |
| | 41 | * Update CSV readers to be multi threaded? |
| | 42 | * In (production) environment it's not a bad idea to put the java executable in the Oracle VM that part of the database. |
| | 43 | * Last but not least, Test if data is loaded correctly (Test from Anco). |
| | 44 | * We should make sure that the data is always loaded into the right format (this means that it always end up the right way in database). |
