I had actually thought about the upgrade paths for DB schemas and I was thinking of coding up a schema executor that would store a schema version in the db and could then be used to apply appropriate "diff" or "clean" schemas against the DB as needed. I think schemifier generally does a very good job, but this would give more control over exactly what's going on in the DB. As for the custom fields, I think it sounds interesting but I think I want to start with the basic fields as I have them defined and I can look at it more in phase 2.
Derek On Wed, Oct 28, 2009 at 3:20 PM, Naftoli Gugenheim <naftoli...@gmail.com>wrote: > > I hear that. > Personally I think it would be more maintainable, not less; there's just a > bit more upfront complexity, although it's something I've already done and I > can share my code. You could trivially have flexible user-defined fields. In > my project you can edit the fields and the lookup tables via the web > interface. > Another consideration is, if you add more hardcoded MappedFields at some > point and a user installs the new version, it will have to schemify. So > you're running Schemifier on a populated production database. There isn't > necessarily anything wrong with that though. (Although recently I corrupted > a database that way: maven had upgraded H2 to a newer beta, which thought my > tables didn't exist. So Schemifier created new ones, wiping it out!) > But again, it depends what you want it to be. > > > ------------------------------------- > Derek Chen-Becker<dchenbec...@gmail.com> wrote: > > The goal is to have a system that we can use for Lift's issue tracking. I > don't know that it has to be as big and bad as, say, JIRA, but it needs to > work well, have a reasonable set of features, and be usable by other people > if they want it. I'm open to suggestions on architecture, but at this point > I would like to keep things relatively simple so that this doesn't grow > into > something that I can't finish. > > Derek > > On Wed, Oct 28, 2009 at 2:39 PM, Naftoli Gugenheim <naftoli...@gmail.com > >wrote: > > > > > What is the goal of this system? Is it to be a nice, useful ticketing > > system that will serve as a demo to Lift? Or is it also to be a product > that > > will eventually compete with other issue trackers such as Lift? > > If you're thinking big then I would suggest to think in terms of > > flexibility and extensibility. In particular I would not hard code > > attributes of the ticket but, at the cost of more starting complexity, I > > would have the fields be looked up in a table. I have done this more or > less > > in two projects. It's tricky with Mapper but when you get it right is > very > > powerful. I'll try to upload my code later this week if you wish. > Basically > > the idea is that you have a table or tables of fields. Fields come in > > different types, including lookup, which is what priority would be, > except > > that instead of the choices being hard coded they are in a table that is > > editable. So lookup fields specify a lookup table. There can be number > > fields, etc. This way plugins can add fields. For example Trac has a > plugin > > that tracks hours. Of course you could just include every single possible > > field hard coded. It all depends what you're aiming for. > > > > > > > > ------------------------------------- > > Derek Chen-Becker<dchenbec...@gmail.com> wrote: > > > > OK, I just pushed the initial revision of my model to GitHub at > > http://github.com/dchenbecker/LiftTicket. I think that this covers most > of > > the features that Marius discussed in his response. I agree with all of > it, > > although I'm not 100% sure about having both a severity and priority > field > > on the ticket. This was kind of a code vomit, so I'm going to split the > > classes out into separate Scala files once I get some feedback and a > better > > idea of what needs to be done. > > > > Cheers, > > > > Derek > > > > On Mon, Oct 26, 2009 at 12:29 AM, Derek Chen-Becker > > <dchenbec...@gmail.com>wrote: > > > > > I'm a fan of Trac, which is one incarnation of Wiki+Tracking+Planning. > > I've > > > set up a repo here: > > > > > > http://github.com/dchenbecker/LiftTicket > > > > > > My preference is for this to be an issue tracking system first and a > > > Wiki/CMS second, but I'm open to any and all ideas on how this can be > > > fleshed out. I would also like to plan on doing a couple of iterations > to > > > get it all working. I like Marius' list of features but I'd like to > start > > > with a subset of those and expand it. My first "milestone" would be > > getting > > > it to the point where it could self-host its own planning for > > enhancements > > > and bug tracking, and I think I can do that with a small set of initial > > > features. > > > > > > Derek > > > > > > > > > On Sat, Oct 24, 2009 at 9:17 PM, Naftoli Gugenheim < > naftoli...@gmail.com > > >wrote: > > > > > >> > > >> How about we integrate the wiki, blog, forum, and issue tracker into > the > > >> CMS? ;) > > >> Seriously, maybe it would be a good idea to create a repo and list, > and > > >> start serious discussion on all aspects of its design. Maybe it could > > become > > >> a big community project, with lots of feedback to Lift. > > >> > > >> > > >> ------------------------------------- > > >> jlist9<jli...@gmail.com> wrote: > > >> > > >> > > >> CMS, wiki, blog, forum also sound more interesting than bug tracking > > >> system to me :-) > > >> > > >> On Sat, Oct 24, 2009 at 11:13 AM, aw <anth...@whitford.com> wrote: > > >> > > > >> > I don't mean to be negative, but are other options being considered > > >> > besides a ticketing system? I kind of wonder if the effort is worth > > >> > it when excellent alternatives exist (like JIRA -- their Git > > >> > integration may interest you: > > >> https://plugins.atlassian.com/plugin/details/4984 > > >> > -- I have used their Subversion integration and was very pleased). > > >> > > > >> > I would be far more interested in seeing something done for the > > >> > benefit of the Lift Web Site. (Is it written with Lift?) I don't > see > > >> > a Lift CMS -- and that is something that could evolve well over > time. > > >> > I think it is important for a web framework to use their own stuff, > > >> > and it should be indicative of the cool things that it can do, > > >> > stability, scale, and performance... (I am amazed that I have seen > > >> > rather poor demonstrations of this, specifically by Adobe and JBoss > -- > > >> > but again, I'm not trying to be negative...) > > >> > > > >> > I see the Lift site integrating Google Analytics... Is that > something > > >> > that could be "out of the box" with Lift? That could be a selling > > >> > point to people making external web sites. > > >> > > > >> > Another area that would be neat to develop is instrumentation. Sort > > >> > of the JMX-Console equivalent for Lift. For scalability and sizing > > >> > analysis, this would be really useful. > > >> > > > >> > > > >> > Having said that, one major feature that I feel is missing from > github > > >> > is the lack of attachments for an issue. How do you attach test > cases > > >> > or patches for an issue? > > >> > > > >> > > > > >> > > > >> > > >> > > >> > > >> >> > > >> > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
