I'm trying to understand more of the details of what I need to do for database access for a LabKey module I create. Here are my current questions:
1. Is the Schema XML file for my module only used for running the developer run test, or does other code depend upon it too?
2. Every single field, table, and view my module will require needs to be manually created in the postgres/mssql .sql scripts for my module, correct?
This includes the special fields defined in the Entity class?
3. I understand that the Table class is the workhorse class I will use most often for datbase access. Many Labkey modules define a custom implementation of the TableInfo interface. Is this also a crucial interface/class that I need to understand to get the most out of LabKey's database access facility? If so, what are good LabKey examples of this class I should use as a reference?
4. If I create a Java class that extends Entity and I define some properties on it that are not defined on a corresponding database table, those fields are safely and automagically ignored when saving and loading instances of that class from the database, right? Likewise, properties that I define on that class that do have corresponding fields in the database table are safely and automagically persisted without any further implementation requirements, right? |
| |
| Peter responded: |
2008-01-02 17:37 |
Scott,
1. The the information in the Schema XML file is used by a few other parts of the server if it is present. For example, if a column definition in table.XML contains the displayWidth attribute, a data region based on the underlying table will reserve that much width for the column. The only part of the server that *requires* tablexml is the DbSchema regression test.
I am working on documenting the entries in tableInfo.xsd and will add a messsge to this thread when it is ready.
2. you are correct.
3. The tableInfos you see that are created in code are generally the ones used by the Query facility. The TableInfos that are created from the table xml and the database tables and views crated by the .sql scripts. both types of table infos can be attached to a data region and have the same basic properties that govern the way they are shown by a data region. I would look at the issues module and schema for a relatively straightforward example of starting with some basic tables defined in the database and adding to them some TableInfos used in the Query module.
4. I believe you are correct, that when you pass a bean to one of the table methods that takes a bean as a bean as an input parameter, bean properties that do not match the database column names are ignored. Remember that beans as input parameters and output results is only one way to work with the Table object. Beans are usually the right way to insert and edit single records from a user interface. If you are filling a grid you will probably want to use a ResultSet rather than an array of beans.
Peter |
| |
|
|