You got normal deals working? That would be cool :)Originally Posted by Jordan
Now that i'm back home i plan on getting to work Crowley is going to be forked into Revelation-SF and a site should be available soon with more information on the project and how to get involved.
Wired deals are now working!
Structure is just the same need to implement the purchasing section but that looks rather easy.
That was me messing with deals :P
Ah ok, good to know.
Yeah, the structure for Ecotron wasn't updated.
Started the rewrite that uses Spring Data instead of manually handing data access :)
I do don't know what you mean by that but nice update! :D
From what I understand, Spring is more efficient in handling transactions for Hibernate (data queries and stuff)
Hibernate + Spring + BoneCP = Best ^>^
Great! Keep up the good work!
Basically i can remove the code for hibernate in the composers and just ask the DAO which is handled by Spring Data for what i need which will handle transaction management etc automatically.
Redesigning the database again to make it yet again more efficient, wont be the most "user friendly" when editing it manually so i might write a basic tool to add items and pages to the catalog since the format is nothing like what people are used to in this section.
Well, maybe it's a good idea to make it a bit more user friendly instead?
I guess it will be user friendly to setup etc.
But there's no need to make the code user-friendly if people don't understand the code, then they need to improve and learn!
Looking good :)
He's talking about the database as far as I know. And instead of creating tools for editing the database, I think it's better to make it more user-friendly instead. It doesn't have to be that simple. But just a logical structure that everyone with basic understanding of databasing understands. And it doesn't even have to be that basic.
The structure is logical however it is different than what people are used to, the issue with making it easier to follow will mean having N extra columns for every catalog page which may not be needed (and we'd need a way to know which are in use MORE COLUMNS!). Doing it the correct way may be harder to edit for the average joe but the speed improvements are dramatic. I'd rather do something right than make it easy and implement it wrong.
On first run the server will install it's self and setup the initial database, however due to the nature of some things a "tool" will be made to make adding things such as catalog pages and possibly rooms easier (simple xml or json file).
---
To expand a catalog page can have many headings and many "bodies" or what every you want to call them in the past three rows in the database have been used and the structure of the pages have been hardcoded in a switch statement, the correct way to handle this is by having an additional table so you can do something like
Doing it this way allows you to correctly generate pages dynamically and means the server doesn't need to be modified when new page structures are introduced. In modern servers this becomes more complicated because Sulake introduced "Deals" (See Wired Deals) in the catalog, because of this you also have todo the same for the articles. So you can use one query to load the pages then you require 2-3 additional queries per-page to obtain the needed data. To speed up access this data is cached after the first request and stored in memory until either the system is required to release it (low memory/shutting down) or the cache is deemed "stale".Code:SELECT headings FROM catalog_heading WHERE page_id = ?; SELECT body FROM catalog_bodies WHERE page_id = ?; SELECT article.* FROM catalog_articles AS article WHERE page_id = ?;
A stripped down example of it can be seen here:
Working on the database structure with Moogly.PHP Code:ServerMessage serverMessage = new ServerMessage(127);
serverMessage.append(catalogPage.getId().intValue()); // id
serverMessage.appendString(catalogPage.getLayout()); // layout
Set<CatalogHeading> headings = catalogPage.getPageHeadings();
serverMessage.append(headings.size()); // heading count
for (CatalogHeading heading : headings) {
serverMessage.appendString(heading.getHeading());
}
Set<CatalogBody> bodies = catalogPage.getPageBodies();
serverMessage.append(bodies.size());
for (CatalogBody body : bodies) {
serverMessage.appendString(body.getBody());
}
// Articles...
PiratePad: ro.kumsNo4ZlgY / Latest text of pad hkUPg2h7ES
Last edited by Jordan; 05-05-12 at 06:03 PM.
I think you mean going through normal database design procedures of normalization and to eliminate multi-valued dependencies(0NF/UNF to 1NF), partial dependencies (1NF to 2NF), and transitive dependencies (2NF to 3NF/Final).
Technically, this is just a way to draft a database design, and to get rid of inconsistent and redundant data - but soley does not mean it will improve performance. The typcial relational database (in this case, MySQL, and most likely you are using their default engine "InnoDB") will automatically optimize the query for best performance.
I quickly scanned through that database design (the link you posted) and you guys are on the right track. A strong, relational and consistent database is the first step. Ofcourse though, you won't be able to finish the whole design at first, as you'll have to add/delete/modify it as you progress with your server
Good luck!
Last edited by TheAJ; 05-05-12 at 06:47 PM.
