File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Database Schema / Facade Interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Database Schema / Facade Interface" Watch "Database Schema / Facade Interface" New topic
Author

Database Schema / Facade Interface

Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi,
I have tried at least 3 possible solutions to provide flexible facade interface, which would allow the client application not be sensibile for database changes and I just have got lost:
- standard bean-manner class and getMetaData to get length of fields:

- just provide getMetaData method; All methods from DB would contain String[] in method signatures as in original interface
- RecordModel containing values, fields and it description as you suggested, but I don't know if I should keep track on the order of elements inside.

I like the idea about RecordModel the most, since I don't have to care about data types on this stage, but I don't know how far should go not to loose points for GUI Client.


1) Should I maintain field descriptive names and descriptions, used for JTable and search fields, on the client or you dynamically pack them also in the RecordModel? (see Field class)
2) Should I use indexes in RecordModel to identify the appropriate field/value in case columns in the database change their order (findColumnByIndex/ByName)?
3) Should I care about the order of elements in the array if tablestructure changes or use the fixed initial order as described in database schema in specification?

Tx
Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
Hi Vlad,
your Record Model looks good. I am doing something similar.
SB
[ August 12, 2003: Message edited by: S Bala ]
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
That is right.
1) I ment not a database name of the field, but distrciptive name:
owner is database field name
customer is descriptive field name.
Or you let your JTable column name show the database field names ("owner")?
2) And the major question is:
MetaData metadata - does it have only column number and name or it has also the index?
Let's take an example:
Database Table Columns are:
name, location, owner.
After some time Columns are changed:
name, owner, location.
Client application doesn't know about that and still
calls update or find method with the argument having fields in old order:
name, location, owner insead of name, owner, location.
It can be fixed by having an index: through this index the right order of fields can be aquired: int findColumnNumberByIndex(int index).
3) Should use then this Record class only for read method, or for find, update, create also?
Tx,
Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
HI Vlad,
Putting the fields in an array or linked list of fixed order should be fine.
Since this is a flat file and not a relational one, the respomsibility is on the user to follow the order. We can only check the column length.
Even if we index the fields, the user can deliberately enter wrong values.
Both name and location are 64 bytes in my assignment. The user can wrongly enter name as "Boston" and location as "My INN" and the system won't complain.
Thanks,
SB.
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
Thanx for reply.
If you are right it makes then no sense to provode the method:
RecordModel read (int recNo) instead of String[] read (int recNo).
It would be suffecient to have additional Fields[] getMetaData() method which would return array or list of Field object having name and length of the field as its attributes. Correct?
You still didn't say your opinion if we should use database field names or descriptive name in JTable columns?

Tx,
Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
Hi Vlad,
You are right. I did not change the interface at all.
But there are some instances wherein I need to know if the particular field
is "Owner" or some other field to do some specific logic.
I have a constants class wherein I am putting them.
eg. RECORD_OWNER="owner".
Regarding using the names in GUI-
I have not designed the GUI yet... some ways to go
There is a reference to the field list in the Record object.
But you can use either from the field list of Hardcode it on the GUI. IMO hardcoded labels should be fine.
- SB
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
I did not change the interface at all.
But there are some instances wherein I need to know if the particular field
is "Owner" or some other field to do some specific logic.

Now I am confused Your statement is a bit contradictory.

1) to identify field as an owner you have to have method in Record class int findColumnNumberByName(String name);
2) if you didn't change the signature of methods in interface you had at least to provide Record getMetaData() method in new interface or adapter class, which deliveres this information.

Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
Vlad,
I think both of us are looking at the same problem differently. Besides, I am yet to do the GUI. I have a reference to the Metadata list in my record object, and a getMetaData() in the Record class.
If need to compare the field name, I do something like this..

RECORD_OWNER = "owner" is an entry in the constants class.

Hope this helps..
- SB
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
Originally posted by S Bala:
I think both of us are looking at the same problem differently. Besides, I am yet to do the GUI. I have a reference to the Metadata list in my record object, and a getMetaData() in the Record class.

Ok. It looks like you use it only on the server, otherwise you had to add some kind of method to the interface used by client.
I beleive a user need the object at list to be able to contol the length of entered fields (hotel/location) for search,
but your are right: both of us are looking at the same problem differently.
Tx,
Vlad
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11503
    
  95

Hi Vlad,
Having a facade (or a Data Access Object) in front of the database is a very nice idea.
Should I maintain field descriptive names and descriptions, used for JTable and search fields, on the client or you dynamically pack them also in the RecordModel? (see Field class)

I guess one issue here is whether you are building a generic database and a generic database server, or are you building a Hotel Reservations database and a Hotel Reservations database server?
If you are building a Hotel Reservations database and a Hotel Reservations database server, then it makes sense to do data type conversions (if any) close to the database, and return the correct type. Likewise it makes sense to return a descriptive name for the columns.
However if you are building a generic database and a generic database server, then you really do not want to do any data type conversions or adding of descriptive names at the database level.

Should I provide these method to map columns to its indexes in case table structure changes?

I had similar methods in my database server. These are generic methods, so it does not matter what type of database you are serving, they will still work.
Should I use indexes in RecordModel to identify the appropriate field/value in case columns in the database change their order (findColumnByIndex/ByName)?

I ignored column position until I got to the client side code. Then when puttng data into my TableModel I did a lookup on the expected column name to get the index of the column, and then rendered that column as Integers. (I also had constants for my column names, so that if the column name changed, only the constant would have to be changed).
Should I care about the order of elements in the array if tablestructure changes or use the fixed initial order as described in database schema in specification?

I personally think this could be one of those "future enhancement" issues that we could think about. There are issues with the database schema provided, and I could see a future enhancement requiring changes to column names, order, additional columns .... The way I wrote my code, it didnt matter if the column order changed, or if columns were added or removed. And if the column name changed, then only one thing needed to be updated.
Should use then this Record class only for read method, or for find, update, create also?

I think it works well for all methods. Your find method may require criteria and the column (name) in which to find it. Your update method will either require you to get the column order correct in the client side, or send the data in a Record which contains the data and the column names in which they are to be stored - the server can then sort it out.
.... if you didn't change the signature of methods in interface.....

Just want to check - we are talking about using these methods in an interface you have created for clients to access your server. We are not talking about changing Sun's interface. Correct?
Moved from a PM response
DataInfo class doesn't have such a method like
int getFieldNumberByName (String name) or int getFieldNumberByIndex (int index),
which would allow the Client to keep trace of the proper order of columns (in case the database table structure changes).

No, but it was easy to add that functionality to the database, or you could easily determine the correct order since the meta data was included with every set of returned records.
How far did go by FBN to provide this flexibility?

FBN did not provide this functionality, but with what they did provide it was only a small step to add that functionality in.
why does the class DataInfo has
private FieldInfo [] fields;
at all?

The supplied classes in FBNS were (according to the instructions) written by "an undergraduate student in for work experience during the summer vacation". So there were parts of the supplied code that were not well architected or implemented.
Regards, Andrew
[ August 13, 2003: Message edited by: Andrew Monkhouse ]

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Andrew,
Thank you very much for your clear detail answer!
All my concerns (I am stocked with the designing this problem already 3 weeks) are solved by ONE message from you! THANX!

Just want to check - we are talking about using these methods in an interface you have created for clients to access your server. We are not talking about changing Sun's interface. Correct?

Exactly, that is why I called this interface DBFacade.


I did a lookup on the expected column name to get the index of the column, and then rendered that column as Integers

Eh? Integer? There are many types there Date, String, Integer, Long? What sense does it make to render all column values as Integer?
I understood you that no index is for our assignement required, since
it is Ok that we hard-code database field names on the client.
That is my general understand of what you have that above:

MANY thanx,
Vlad
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Hmmm... seems like Andrew has said everything I might have said, and other good comments as well. So this means that in the future I should just wait for Andrew to post.
I agree that it's acceptable to hard-code the indices into the client. But it's also fairly easy to look them up using the MetaData, and make the code a little more robust. Not required, but I like it. And note that if you set up table columns using TableColumnModel, you can use setModelIndex() on a TableColumn to handle the appropriate mapping. Or you can do this yourself in code elsewhere.


"I'm not back." - Bill Harding, Twister
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Andrew and Jim,
Thanx you very much for your help.
I don't know why, but both of you understand exactly my question, and
what is more surprising: I absolutely understand your comments!
I am now destroying all my program toi build in the Facade Interface on the server (Adapter for the standard low level DB Interface) providing appropriate signatures for methods and MetaData. Since I do it anyway, I think it is better to move lock/unlock invocation also to the server.
So client controller instead of doing following:

will do the this:

It is flexible, simple, no concerns about client crash, because all the logic goes now to the server (middle tier).
I am now worried about following:
I have now totally new local/remote facade interface, which is used by client.
If Sun would want to test (with automatic test) standard DB interface in local it is not a problem, but they will not be able to test it in network mode, because only Remote Facade Interface is available over the network.
It has different method signature and has no create/delete methods, because
they are not needed by client (they are implemented only in DB Implementation class)

I don't have requirement in specification, that my client must implement DB interface, but there is on requirement:
"Network server functionality for the database system"
Should it be OK???
Tx.
Vlad
[ August 13, 2003: Message edited by: Vlad Rabkin ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11503
    
  95

Hi
[Jim]: So this means that in the future I should just wait for Andrew to post.

Funny, I've been waiting for you to post
[Vlad]: I absolutely understand your comments!

We can fix that !
[Vlad]: Sun [...] will not be able to test it in network mode

I don't see a problem with that: Sun do not mention in their requirements that you have to provide them with a networked way of testing. A large number of the solutions I see discussed here have business orientated network interfaces, which means that they also wont be testable by an automated solution. I think the only way that Sun can test is by using the Data class. They should be able to simulate multiple users with that, but I cant see any way for them to test your network interface programatically.
[Vlad] there is on requirement: "Network server functionality for the database system"

That is slightly more of a concern. Depending on the exact wording and the context, you might want to think about creating networked versions of the "create" and "delete" methods. But even then, you possibly do not have to match the method signature for those two methods in your networked code.
Regards, Andrew
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Andrew,

[Vlad]: I absolutely understand your comments!
[Andrew]: We can fix that

Don't do it!
Andrew, thanks a lot again!
I should have asked about this generic framework three weeks ago, I would not loose then this time for my reasearches

Vlad
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Database Schema / Facade Interface