NX: Database vs Data / MetaData

[Philippe Maquet]

Hi Vlad,
I'm sorry to reply to your private message by posting this new thread, but I think it's better to share our discussions on the forum.

Hallo Phil,
You use you this method. I am trying to understand how it should work exactly.
Example:
Client->Database->Data
Database is the a class, which extends Data and implement new interface (not DB/DBAcces), to provide getMetaData methoid and additional find methods.

Client calls readRecord(6);
Database calls readRecord on Data and gets dataResponse String[].
It creates then a new databaseResponse String[] and fills it by doinng following:
databaseResponse[0] = dataResponse[metaData.getIndexByName("hotel")];
databaseResponse[1] = dataResponse[metaData.getIndexByName("location")];
...
That is what you should theoretically be doing, because you said you do it only in your business layer (middleware).
or you do it on the client:
client calls readRecord.
Database just calls readRecord on Data and delivers response, without parsing it, on the client.
And the client makes this (what Database does in first example).
Hiw do you make it (first or second), if I understand you not correct could you PLEASE send me an example!

Tx,
Vlad

I think that tou are refering to this thread (No need for a locking manager?) because it's the only one in which I talked about a Database class.

Client->Database->Data
Database is the a class, which extends Data and implement new interface (not DB/DBAcces), to provide getMetaData methoid and additional find methods.

My design is quite different. My schema is :
client_1->network_connection_1->data_1 \
client_2->network_connection_2->data_2 -> database
client_3->network_connection_3->data_3 /

where data_n is a Data instance extending Object and implementing DBAccess, and database if a Database instance extending Object and implementing ... nothing.
Our data access class (the one which ultimately accesses a given db file) must be a multiton (one and only one instance per database file), and it's the Database class in my design. A multiton, because, per database file, there are a lot of things that you must share among client connections : a read cache if you have one, a write cache if you use one, metadata information, and so on.
Now, why not this simpler schema ?
client_1->network_connection_1 \
client_2->network_connection_2 -> data
client_3->network_connection_3 /
Just because :

I wanted to add this little plus to the locking requirements : deadlock prevention

Any deadlock prevention scheme needs to know "who" claims for and owns locks

The lock/unlock methods in interface DBAccess have no "who" in their parameters

Data must implement a DBAccess interface that we cannot change

We are free to define our Data constructor as we want (including public Data(dbFileName, "who"))

We are free to implement our lock() method as we want, including this :

public long lockRecord(long recNo) {
   return database.lockRecord(recNo, "who");
}

Notice that in a first LockManager design, I didn't need that "who" parameter : the owner of a lock was Thread.currentThread(). But as a few "big foots" people like Andrew and Max convinced me that it could lead me to an exam failure, I had to find that little "trick" to get that "who" in another way while still respecting the given DBAccess interface.
Now about the Data (or Database) getMetaData() method :
As in any database system, you have two types of information that you can get about a given table : contents (multiple - the records) and structure (unique - how the records are structured). So I think it's good design to have a separate MetaData class which stores all structural information about the table, and to which Data may delegate any operation on that unique information (read the file header, write a file header, expose information on fields, etc.).
I hope it was clearer here,
Best,
Phil.

[Vlad Rabkin]

Hallo Phil,
Thanx for reply:

I think that tou are refering to this thread (No need for a locking manager?) because it's the only one in which I talked about a Database class.

Not at all.
My question has nothing to do with design of Locking mechanism.

As in any database system, you have two types of information that you can get about a given table : contents (multiple - the records) and structure (unique - how the records are structured). So I think it's good design to have a separate MetaData class which stores all structural information about the table, and to which Data may delegate any operation on that unique information (read the file header, write a file header, expose information on fields, etc.).

That is exactly what I am interested in.
That is what I am trying to do: I have the class MetaData and everything I have told about, but what I don't understand is who exactly use MetaDada getMataData().getColumnIndexByName(String columnName) method to get approriate index of specific field:
you Database class? Data class which implements DBAccess or your client?
Tx,
Vlad

[Philippe Maquet]

Hi Vlad,

That is what I am trying to do: I have the class MetaData and everything I have told about, but what I don't understand is who exactly use MetaDada getMataData().getColumnIndexByName(String columnName) method to get approriate index of specific field:
you Database class? Data class which implements DBAccess or your client?

OK, I've been confused by your "Client->Database->Data" relationship.
First comment :
A field has more interesting information that its index in the fields collection (currently its index, length and name but in future enhancements, its type would be a good candidate).
So it's better to have MetaData just returning a Field object, either by index or by name :
public Field getField(short index);
public Field getField(String name);
With the Field object obtained, you can call :

field.getIndex()

field.getName()

field.getLength()

field.getType() // future enhancement

what I don't understand is who exactly use MetaDada (...)

An obvious answer would be "anyone interested in the information it can give".
But practically, it will be you business tier which must :

know the length of a given field to tell a client GUI how many characters may be entered by the user

know which index to use to update a String[] fieldValues in a book() method

...

Cheers,
Phil.
[ August 04, 2003: Message edited by: Philippe Maquet ]

[Vlad Rabkin]

Hi Phil,
Exactly. I have called this class ColumnMetaData (instead of Field).
Now we are very close to whhat I want to find out
I have asked you 3 times, and each time you say business tier:

But practically, it will be you business tier which must :

know the length of a given field to tell a client GUI how many characters may be entered by the user
know which index to use to update a String[] fieldValues in a book() method

I have problems understanding it (since I call business tier a middleware - the server logic). It seems that you means something different, otherwise I don't really understand why U mention Client GUI.
I understand you as follows:
1) your GUI client invoke separately method on
data object/ network connection object:
GUIWindow class:
MetaData metaData = Data.getMetaData();
Field fieldHotel = metaData.getField("hotel");
Field fieldLocation = metaData.getField("location");
// validator
tfHotel.setDocument(new MyValidator(fieldHotel.getLength()));
....
// search request generator
String[] criteria = new String[metaData.getColumnsNumber];
criteria[fieldHotel.getIndex()] = tfHotel.getText();
...
// update request generator
String[] data = new String[metaData.getColumnsNumber];
criteria[fieldHotel.getIndex()] = tfHotel.getText();
...
So, it is used :
- to validate fields length
- to generate requests: update, create and find
- to interpret the response from the server by read
2) your server (Data) will use one more time to interpret requests
and parse the response ?
And if all this is true, I thought Data class or another class between
Network-Connection object and data_n object must exist which implements other interface than DBAccess to provide getMetaData ?!
Sorry for annoying you with the questions,
but it looks like I need learn to form my questions a bit more clear, because it costs every time 2-4 mails before somebody understands what I ask ...
Vlad

[Philippe Maquet]

Hi Vlad,

Sorry for annoying you with the questions,
but it looks like I need learn to form my questions a bit more clear, because it costs every time 2-4 mails before somebody understands what I ask ...

Don't worry. Everytime I feel misunderstood on this forum, I ask myself if it's due to the fact that I don't master english... But you're right : let's go on in french (you're lucky, I was just kidding).

I have problems understanding it (since I call business tier a middleware - the server logic). It seems that you means something different, otherwise I don't really understand why U mention Client GUI.

No you don't misunderstand. I just mentined the GUI client because it's part of this global relationship : database <--> middletier (businesstier is a synonym) <--> client tier.
I understand you as follows:

1) your GUI client invoke separately method on
data object/ network connection object:
GUIWindow class:
MetaData metaData = Data.getMetaData();
Field fieldHotel = metaData.getField("hotel");
Field fieldLocation = metaData.getField("location");
// validator
tfHotel.setDocument(new MyValidator(fieldHotel.getLength()));
....

No ! The client doesn't need to know anything about the database ! From the client perspective, I only see two main entry points (methods if you prefer) in the business tier :

find(...)

book(...)

plus a few "helper" methods like the (very badly named) :

tell_me_which_fields_I_may_search_on_along_with_their_distinct_values(...)

tell_me_how_I_should_check_a_valid_room_owner()

...

That three-tiers design is not just "politically correct" (I hate politically-correct things BTW ), it lets you move from our Data class to an Oracle system without any need to break client code. And BTW, that "plus" is in our requirements :

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

Well, no disruption at all when the database tier evolves is the minimum you must do, IMO.
Best,
Phil.
[ August 04, 2003: Message edited by: Philippe Maquet ]

[Vlad Rabkin]

Hi Phil,

let's go on in french

I knew you are from France:
you write your mails in appropriate time and your name sounds like a French
name.
You are right, I guess my English is not perfect, but a bit then French!
Ok.
I agree with you totally, 3-tier architecture allows us to be independant
from back-end tier: it doesn't matter if you then Oracle or our file data access system,
but I am now even more confused

find(...)
book(...)

Well, your design make me wonder:
1) it means you lock/unlock on your business-tier: database server, but not on client. Correct?
2) how you then let your business tier know what type of search you want to execute (you have only one find method)?

tell_me_which_fields_I_may_search_on_along_with_their_distinct_values(...)
tell_me_how_I_should_check_a_valid_room_owner()

Whatever you call these classes, the are on the client and they must
use MetaData and Field classes to find out at least the length of the fields, no allow a user to enter too many symbols for hotel name or location for search!? So, what do you mean by saying you don't use it on the client, but only on the server (business tier)!?

Vlad

[Philippe Maquet]

Hi Vlad,

1) it means you lock/unlock on your business-tier: database server, but not on client. Correct?

Yes, you got it definitely. Locking is really not a client stuff IMO.

2) how you then let your business tier know what type of search you want to execute (you have only one find method)?
tell_me_which_fields_I_may_search_on_along_with_their_distinct_values(...)

Well, our aim is not to have the same implementation of our common assignement : BTW, we could have the same grader... ;-) So let's keep as generic as we can.

Our business tier could know which field are "searchable" from some property (see "suncertify.properties" in your instructions and the GUI requirement which comes along). Our business tier could know all possible distinct values of a given field after a call to some Field.getDictinctValues() method. And it could wrap both information in any Object to send the information to the client tier...
Mmh. If you are still we me here, you just have to code it, in your own way. And if you aren't, I don't think I can find clearer words to explain what I mean !
Best,
Phil.
[ August 04, 2003: Message edited by: Philippe Maquet ]

[Vlad Rabkin]

Ok Phil,
I beleive I got yout idea. It seems that I have totally different design,
so don't worry we not has simular implementations
Tx
Vlad