NX: exposing the MetaData to the client

[Ulrich Heeger]

Hi everyone,
I have some questions how to expose the MetaData to the client:
I have following design for the Data-Layer:
the header-informations are read by DataSchema, a singleton instance.
DataSchema also creates an immutable object MetaData (thanx, Vlad) which provide informations needed by the client.
Further DataSchema contains a getMetaData method which returns MetaData.
In local mode the client can call getMetaData from DataSchema directly. For the remote mode, I have created a new Class called RemoteSchemaImpl implementing the remote interface RemoteSchema.
RemoteSchemaImpl's only method beneath its constructor is getMetaData, returning the serializable object MetaData.
1. Sounds a little bit complicated, I know, but I don't know a better way to provide the MetaData to the client for the 2-tier solutions.
Comments?
Thanks a lot in advance
Ulrich

[Vlad Rabkin]

Hi Ulrich,

Sounds a little bit complicated

Agreed
I don't think it is a good idea to let dataSchema have a method getMetaData(), since DataSchema is MetaData.
There many ways to do it.
Example 1:
You don't have MetaData class. Your Data class has a method getDataSchema (or getMetaData()), which returns DataSchema.
EXample 2: If your DataSchema contains some information needed for the server application and you don't want to expose it to the client:
You can have two classes:
One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.
Your Data class will have than MetaData getMetaData() method, which returns actually DataSchema. It would hide any complexity from the client.

abstract class MetaData {
...
 public Column getColumn(in index){
  return ...
 }
}
class DataSchema extends MetaData {
  public long MAGICCOOKIE = 0x00;
  public int getHeaderLength(){
    return ...
  }
}
class Data {
  private DataSchema schema;
  public MetaData getMetaData(){
   return schema;
  } 
}

Best,
Vlad

[Ulrich Heeger]

Hi Vlad
thank you for your reply.

One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.

That sounds cool. I will try this way and surely will have some more questions to ask
Greetings
Ulrich

[Nicholas Cheung]

Hi Vlad and Ulrich,
I have finished the core part, and now is trying to fine tune the programs.
At first, I read my MetaData from the database file, and I have this:

// Data.java
int no_of_header = readInt(); // Assume RAF is at the right place
MetaData[] md = new MetaData[no_of_header];
for (int i=0; i<no_of_header; i++) {
    md[i] = new String(readHeader()); // Assume readHeader() reads the String
}
// MetaData.java
public class MetaData {
  private String name;
  private int length;
  // the getters and setters
}

And I get the following:

md[0].getName(); = "name"
md[1].getName(); = "location"
...

These string values will be displayed in the JTable's header.
However, in my instructions:

[B]
Descriptive                          Database field
name                                 name
[/B]
Hotel Name                           name
City                                 location
Maximum occupancy of this room       size
Is the room smoking or non-smoking   smoking
Price per night                      rate 
Date available                       date 
Customer holding this record         owner 

My question is:
Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?
I have tried this before, I put this mapping into the "suncertify.properties" file, but when it really display in the header field, it makes the length to be very long, which is very ugry
Any comments?
Thanks.
Nick
[ December 08, 2003: Message edited by: Nicholas Cheung ]

[Vlad Rabkin]

Hi Nick,

Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?

Well, I tried to display names from "descriptive name" list. I changed them a bit: Hotel name-> Hotel, Cutomer .... -> Customer and so on.
Best,
Vlad
P.S. I would suggest to change the name of your class MetaData to ColumnInfo or something like that. MetaData logically should a class describing all columns (e.g. the array of columns), not a single column.

[Seid Myadiyev]

I would like to ask if I may "assume" the structure of the record from the instructions document and create a "Room" class based on the assumption with appropriate data types for each instance field. For example:

public class Room
{
  private String name;
  private String location;
  private Integer size;
  private Boolean smoking;
  private Double rate;
  private Date date;
  
  //more code: instance methods, setters, getters
}

Or do I need to inspect the db file at runtime hold everything in abstraction (without any specific instance field names and types) and only make a wrapper for the array of strings which represent the field values? For example:

public class Record
{
  private String[] fieldValuesArray;  
 
  public Record(String[] fieldValues)
  {
   fieldValuesArray = fieldValues;
  }
  //more code: instance methods, setters, getters
}

Thank you!
Seid

[Vlad Rabkin]

Hi Seid,
I would preffer the second option (with array). GUI is required to be developed with option of future functionality enhancements. The second option helps client to do so by providing more generic framework.
Best,
Vlad

[Ulrich Heeger]

Hi Vlad, hi Seid,
Seid,
I have tried also to use the descriptive names, but they're so long, now I will use the shorter field names.
Hi Vlad,
I have now thought a little bit about my further design concerning the MetaData(or whatever I will call it later, now, excuse me, I will keep this name
I.I can't implement getMetaData() in the Data-Class because I'm using the 2-tier approach (I suppose that we are not allowed to add further methods in the DBAccess interface).
Because I have DataSchema as a Singleton, I will have in this class getInstance()-method which returns the singleton (like you suggested, DataSchema extends MetaData):

public static synchronized DataSchema getInstance(String dbPath){   
if (me == null) {            
me = new DataSchema(dbPath);        
}        
return me;
}

Now, some thoughts concerning the exposing of MetaData for the client.
I think I have two options:
1. to add one more RemoteObject which includes a getMetaData()-method or
2.to include this method in one of my two already existing RemoteObjects, ConnectionFactory(Impl) or RemoteDBAccess(Impl). Because I can't add getMetaData to RemoteDBAccess for the reasons I mentioned above, I can add it to ConnectionFactory.
Please correct me, if you see some weak points in my reasoning
OK, let's assume that I choose the option 2:
So in ConnectionFactoryImpl I would have following method:

public MetaData getMetaData() throws RemoteException;

this is a kind of wrapper for DataSchema's getInstance() transforming the DataSchema in the User-conforming MetaData.
For the local mode, the transforming from DataSchema to MetaData will happen at the client side and look like:

public static DBAccess getLocal(String dbPath){
MetaData meta = DataSchema.getInstance(dbPath);
setMetaData(meta);
return new Data();

} 

I'm sorry to border you with this mass of code, but I'm a little bit lost.
What do you think about this approach?
Thanks a lot
Ulrich
[ December 08, 2003: Message edited by: Ulrich Heeger ]

[Ulrich Heeger]

Hi Vlad,
sorry to annoy you again
I just wanted to say that I will first try my concept and will probably post my questions in a new thread.
So thank you & see you later
Ulrich

[Vlad Rabkin]

Hi Ulrich,

I'm sorry to border you with this mass of code, but I'm a little bit lost

Stop saying sorry! I enjoy talking to you.
1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.
2.
Solution A:
Well, I did have some kind of "hybrit" between 2/3 tier.
I did have interface DBAdapter. This adapter had no any much of the logic:
- It chained unchecked exception to checked exceptions.
- additional getMetaData() method.
I would solve the problems mentioned by you.
Solution B:
You have a standard interface (say DB) and data class implementing it.
You can create one more interface MyDB extending DB interface (which would have additional getMetaData() method). Then you can
1) just add getMetaData() method to your Data class and make it implement not DB, but MyDB. It is a bit risky (since it may be a breach of specification), but the people in this forum decided that it should be Ok.
2) create MyData class (pretty the same as DBAdapter), which would implement MyDB and call the logic from Data:

class Data implements DB{
  public MyData(String file){
    ...
  }
  public String[] read(int index){
   return ...
  }
  public MetaData getDataSchema(){
   return dataSchema;
  }
} 
class MyData implements MyDB{
  private Data data;
  public MyData(Data data){
    this.data = data;
  }
  public String[] read(int index){
   return data.read(index); 
  }
  public MetaData getMetaData(){
   return data.getDataSchema();
  }
} 

Your RemoteObject can wrap than MyDB instead of DB.
Best,
Vlad

[Ulrich Heeger]

Hi Vlad,
thanks for your help, I will try to avoid the word "sorry" in future, sorry

1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.

That sounds reasonable. That�s also my intuitive thought.
Your further solution looks really good.
In the meantime, I�ve now tested the approach I�ve mentioned above:
So I have now implemented following methods in ConnectionFactoryImpl:

public ConnectionFactoryImpl(String dbPath) throws RemoteException {
meta = Meta.createInstance(dbPath);
}

public RemoteDBAccess create() throws RemoteException{
DBAccess data = new Data();
return new RemoteDBAccessImpl(data);
}

public Meta getMetaData() throws RemoteException{
return meta;
}

The question is if I can argue to integrate the getMetaData()-method within my ConnectionFactory. In this article from Sun
it�s written:

In general, a factory implementation is useful when you need one object to control the creation of and/or access to other objects.By using a factory in RMI, you can reduce the number of objects that you need to register with the RMI registry.

With this statement I could justify the implementation of getMetaData-method or what do you think about that? Shall I post a new thread to ask this question?
Greetings
Ulrich

[Vlad Rabkin]

Hi Ulrich,
I find your approach interesting. You can probably justify it: You don't have to follow patterns and so on. So, it is a valid solution.
However, I would try to avoid it, since your ConnectionObject consufes a bit from the first look. It is hard to comment it: it is a valid solution, but, I PERSONALLY, don't like it. I still beleive it is the best way to provide the client with business user interface containing all methods needed to work with the server (including getMetaData()).
I would like to ask others to join this thread to hear other opinions, since I my approach is, may be, too restrictive.
Best,
Vlad

[Ulrich Heeger]

Hi Vlad,
thank you for your comments.
I have to think a little bit about my concept.
Greetings
Ulrich