Hello Glen,
Thanks for helping in this and I with this much deep information, I can
start working in it. I have started working on this Issue and have
followed your steps.
1. Created a new table in createdb.vm and in migration scripts also. I
have for mow stared working on MySQL.
2. In JPAWeblogEntryManagerImpl class, I have commented updatePathTree
and getRootWeblogCategory methods
3. I have created a new file for now Category.orm.xml and enterd details
of new table. A new class Category in weblogger/pojos.
I have created new files for now and will work on this and add new
position coloum and code regarding this. Other than UI and template
Layer, I think I have covered all files on which I have to work on the
Database and JPA layers ? Please tell me if I am wrong anywhere or
following wrong workflow.
Thanks
Gaurav
On Saturday 21 December 2013 04:59 AM, Glen Mazza wrote:
Hi Gaurav, we use Velocity for our database scripts -- you see a
createdb.vm plus migration scripts (5.0 to 5.1) -- we'll want our
change in both places (IIRC), new users have the createdb run and
Roller upgraders with their current DB's have the 5.0 to 5.1 migration
script run.
We have multiple issues here and I'd like to get this done right (I
plan on helping out where you'd like). Namely, we've moved from a
hierarchical category structure (categories having subcategories
having their own subcatorgories etc.) to a flat single-level structure
(all categories are top level) -- that was done a week or so back.
Problem is, the database tables are still assuming hierarchical (they
will work with flat structures but are overkill--we don't need a
parent ID column anymore.) Also, the JPA objects are designed for
hierarchical but can simplified a bit more to flat structure.
Incidentally, "sequenceNum" is ambiguous about what it means, I would
say "position" or "ordering" (INT null, null for migrators who don't
yet have a position defined) is clearer.
I think the simplest way to handle this--for both new installers and
upgraders--is:
1.) Database: To create a new table, say "category" designed
precisely as we need, and have the migration scripts select from the
old weblogcategory and insert into the new category table. (We then
ignore the weblogcategory table.) We'll need to test the scripts with
at least two databases (2 of probably MySQL, Derby and/or PostgreSQL)
and guess for the others--if we're wrong the user community can supply
a patch fixing it.
2.) JPA: The JPA persistence object (the old WeblogCategory) will need
simplifying/restructuring as it's now flat-level. Indeed, I think
things will get a *lot* simpler here, as it may just be the parent
Weblog holding a list of some sort of Category objects--that's it.
3.) UI Layer: The category.jsp (or whatever it's called) and its
Struts action class will now need to use the new Category object (and
table) instead of WeblogCategory. The UI page will need two changes:
(1) all new categories will be placed (and saved) at the bottom of the
category list (and as result, appear last (right-most) in the category
list, and, later (2) probably have up and down buttons in the table
allowing users to easily reorder the categories as they like.
(Strictly speaking, 1 alone is all that's needed for ordering, as you
can remove/name/delete/recreate categories to eventually get them in
the position you'd like, but (2) of course is much nicer.)
4.) Template layer (haven't looked into this): The templates
(probably just a macro or two) will need updating to ensure that they
output the category names per the new position order.
It's a lot of work, but one advantage is that I'd like to do the same
thing with bookmarks/blogrolls (team discussion pending...), switch
from a hierarchical to flat-level for those too. If we can do this
for categories, the logic/UI design, etc., will carry over 100% to
bookmarks.
I was planning on eventually getting to this myself, so am available
to work with you on whatever parts you'd like. I think going in order
1-2-3-4 and having separate commits may be the cleanest way of doing
this. What's nice about using a brand new table and JPA object is
that the old objects can still work in the code while we're creating
the new, we just don't activate the new until the very end.
WDYT? (Also, other team members on the above ideas...?) Or are there
other Roller tasks you'd like to sink your teeth into instead? I can
look at this otherwise, but this looks like a very good exercise for
someone wanting to get more involved in Roller, as it covers all the
layers of the webapp.
Regards,
Glen
On 12/20/2013 10:43 AM, Gaurav wrote:
Hello,
I have started working on ROL-1981, as discussed in previous
discussion threads I will add new column sequenceNum in
weblogcategory table. Then we can assign sequenceNum to each category
according to websideid. If anyone have some ideas regarding this,
please help me. Also, need some help on how to go with this issue,
and how to add new coloum, I found .sql file, do I need to add there
new column. Also, Is this possible that that when I restart the
roller it will add new column to database ?
Thanks for Any ideas/help.
[1] - https://issues.apache.org/jira/browse/ROL-1981
