I am trying to add a feature on the "Bookshelf App for Java on App Engine Standard Environment" that lists books based on read or not read. The codes are available here https://github.com/GoogleCloudPlatform/getting-started-java
There is a Book.java file that defines the model a book. If I want to add the feature of read or not read do I add a boolean variable in Book.java? Is this a right approach? Or just keep a database table of bookID, user, readOrNot? Or the are some other smart approaches?
In general, a class like Book.java should only contains properties specific to a book like title, author, published date. If you want to add information like number of pages, you would add it to the book class. In the case of the read or not read feature, it is better to keep this information in a database where book IDs would be attached to a specific user. The user class could keep a book read list but I would recommend a database class that exposes an API to get a list of books for a user. The code would be more reusable.
I hope this help you a bit.
Related
I'm creating a RESTful weather by cities service, i.e. a client knows a city ID and wants to receive a weather report in JSON from this city. For example:
{temperature:xxx, humidity:xxx, pressure:xxx}
Two issues:
What should the Get URL be? (My first idea: api/v1/WeatherByCityId/{cityid) but it looks raw and untidy... or is it OK?
Do I need to create two entities: City (table="cities") and Weather (table="weathers") and create a relationship? OR better create one entity WeathersCities(table="weathers_cities") (or whatever...)?
(I'm not gonna use 3rd party weather services, please don't suggest RestTemplate, WebClient, FeignClient, etc. Yes, I will fill the weather data by myself every hour.
Lets say you want to fetch the weather for a city, Lets store the city seperately in a City table and make City Id a primary key and put all the weather related data for the city in a seperate table Weather by keeping a foreign key City Id.
The RESTAPI would then be as such.
https://yourdomain.com/api/v1/city/{cityId}/weather
If your app's scope increases maybe later then you can reuse this same table principle and then the RESTAPI would be
https://yourdomain.com/api/v1/city/{cityId}?parameter=any_entity_you_have_mapped_with_city
To summarize this, If your APP is just going to be about weather in the city then having a same table for both entities is okay. However, if you want that your APP can be used for querying a lot of other information about multiple entities like population, schools, etc then having a seperate table is a much better approach. I would recommend keeping seperate tables for the 2. This approach also makes the DB highly manageable. Let me know if you have some questions. Hope this helps :)
A One to Many mapping of City with Weathers is preferred.
Your weather table will have city_id as a foreign key for mapping.
The URL you suggested is a good way to go and will be easier to maintain if you're going for GET Mapping.
api/v1/weather/{cityid}
It will be more flexible to use so.
I'm using Spring Boot (generated by JHipster).
I have the following services:
/api/market/
/api/market/:id
and
/api/product/
/api/product/:id
all those with GET, PUT, POST and DELETE. But I need to implement one more specific service.
This services should return all the products inside the market X. But to do that, I was thinking to pass in the URL path this call: /api/product?marketID=1, but I will have to make a select in the market table and then get the products (will be easier search in only one table by market_id field).
I don't know if this URL is the best structure and also this kind of search. I know you can search of a specific field on the table the you do a filter, but I tested and I was not able to get a relation field.
I'd like to make a recommendation for how to structure your API, then provide a possible answer to your question.
Typically, RESTful APIs follow the plural-singular principle: given all markets (plural part), find market with id 5231422 (singular part). Reflect that in your URLs with /api/{plural-noun}/{singular-identifier}. So your API would end up looking more like this:
/api/products (all products in the system)
/api/products/:productId (a single product in the system)
/api/markets (all markets in the system)
/api/markets/:marketId (a single market in the system)
To answer your question, then: I recommend you use the "Russian stacking doll" URL design. It appears that your design suggests that a single Market can contain several products in it. Thus you might find this kind of URL a bit clearer: /api/markets/:marketId/products, which fetches all products within that market.
Generally, you want your URL's to be semantic and navigable. So based on what you've already got:
/api/market/:marketId/product
In addition, it is usually recommended to go with pluralization so I would do the following:
/api/markets/:marketId/products
I've been creating a small sample project to display my learnings in JavaFX, and it's completed as far as functionality. My problem now is that The lead instructor has asked me to show a database style relation between the student page and the faculty page, showing that a student has tried to add a course. I've got one page for the student where they can select a course from a table. I then have a faculty page that displays a current schedule table, and a tab on the pane that allows the faculty to add or delete a class. I'm wondering the best way without a database to show the s student has selected a course from the table which they choose to register for. I'm Using TableView for all tables, creating observable lists where I can add items and everything displays perfectly on the tables. I have the add and delete functions working perfectly well also. I only need to find a way to transfer the selection from the student to be viewable by the faculty, perhaps in a text file or something like that. Any suggestion or help is much appreciated.
There are indeed several ways. One you have suggested yourself.
You could write the data to a text file using the PrintWriter class (java.io.PrintWriter). You can recall the data by using the Scanner class.
If there is no need for the data to be stored after closing your program, the textile will be redundant. It would be better practice to store the data in an object/instance which can be aggregated by the faculty.
For a more specific answer, be more specific in your question.
After starting to read a book on OO programming, I am attempting to make my android app more OO. However I am stumped on a simple scenario.
I have a Book object, which can have many say Chapter objects. I also have a search function which searches across multiple books, 97 of them. I end up with many Chapter objects from the Sqlite table.
I felt that it would be useful to the user to be able to see the title of the book on each result, otherwise it might be confusing if there are say two "chapter 5" results.
For that to happen, I need the book title. Should I make it part of my chapter object, like :
chapter.getBookTitle()
Which kind of does not seem right, as I have glued the book name onto a chapter... The alternative is to instantiate a book object for each chapter and somehow reference it, which has its own problems including in android with regards to not being able to pass a reference to an in-memory object to another activity.
Also a book may have many other chapters which were not results in the search, and it may seem like they would return if I was to just instantiate the book.
What is the correct OO solution to this seemingly simple issue? Is it just a matter of learning when not to be dogmatic about the whole OO thing?
More Info:
I am using FTS4 in Sqlite, which accounts for over half of my actual DB size of 80mb. What I am storing is text from 97 books, with chapters in 4 languages. So my FTS at the moment stores:
ChapterId, ChapterNo (withinBook), Lang1, Lang2, Lang3, Lang4, Tags, Notes
The searching is very fast, I retrieve only 50 results. I match any column with a string term, and not one column in particular. So if I type "apple" it will search all the fields above.
Currently as part of my FTS query I am join a join onto Book, fetching the BookId, I later use that to get me the title of the book. However its all in a procedural like style, with no regard to where the information "belongs".
I need the title so I can display it in the results, just for user convenience.
It works well, however I am wanting similar performance or slightly less but with an OO approach as I think that will make more sense to me when I come back to this project after a long pause.
The Chapter object should have reference to the book it came from so I would suggest something like
chapter.getBook().getTitle();
Your database table structure should have a books table and a chapters table with columns like:
books
id
book specific info
etc
chapters
id
book_id
chapter specific info
etc
Then to reduce the number of queries use a join table in your search query.
The approach I would take is: when reading the chapters from the database, instead of a collection of chapters, use a collection of books. This will have your chapters organised into books and you'll be able to use information from both classes to present the information to the user (you can even present it in a hierarchical way easily when using this approach).
You might implement your class model by composition, having the book object have a map of chapter objects contained within it (map chapter number to chapter object). Your search function could be given a list of books into which to search by asking each book to search its chapters. The book object would then iterate over each chapter, invoking the chapter.search() function to look for the desired key and return some kind of index into the chapter. The book's search() would then return some data type which could combine a reference to the book and some way to reference the data that it found for the search. The reference to the book could be used to get the name of the book object that is associated with the collection of chapter search hits.
I'm trying to write a java-based movie database program. It recursively searches a given list of folders, retrieves information about the movie files within, and allows you to search for movies using tags/actors/file resolution/etc, and will show a cover thumbnail of the movie and screenshots.
The program as I have it now stores information (atm only filename/size) in arraylists, and generates a html page with the thumbnails. I would like to use a mysql database instead so it will persistently store the movie information and doesn't have to search through all the folders every time.
I can use a "Media" object for each movie to store all this info, but I'm not sure of the best way to store this in a database. I don't want to just serialize the Media objects because then I would have to iterate through the whole db to search, which would be slow. I assume I need to use mysql queries to search.
I have only a less than basic knowledge of database design although I do have an idea how to use jdbc to create/access a mysql database once I have decided on a layout.
Can anyone give me some pointers on what I need to learn and where to learn it in order to decide how to lay out/index and link the tables for my movie database?
Here's my current Media object:
public class Media {
File file_location;
String filename;
Date date;
int hres;
int vres;
boolean has_tbn;
File tbnloc;
boolean has_ss;
File ssloc;
int length;
String[] actors;
String[] tags;
boolean HD;
long filesize;
String md5;
From what you said, I assume you already know how to setup/create a MySQL database, so I won't bother with that.
First, you will need to make a table for your media. Start designing a column that can store each object in your Media class with the appropriate data type, as well as set a primary key, which should be unique. This is preferably a separate id number. Also be sure to specify which columns cannot be null or blank, to avoid accidentally writing incomplete data.
However, I also see you have arrays for actors and tags. As a designer, I would prefer for these to be in separate tables, with another table joining them to the main media table for a many-to-many relationship. You could also make it simpler and just set it as a long string with a separator that you will parse and place into the array.
You may want to reconsider saving a file directly into MySQL as well. I prefer just saving the file location and keeping the actual file as is.
I think you should also take a look at the sample database the current version of MySQL has, called Sakila, which should also be available for install when you install the latest version of MySQL. It's a database for a video store, and thus has well-designed tables for storing film data and all its related factors.