I meant to reply to this earlier but various things got in the way... I
think I was going to start with: Ah, now that is interesting.
Thank you for pointing that out, Daniel. The hybid approach could work
though I am still interested in working toward a clean model as a
starting point. Regardless, it does look like we would be able to make
use of the information you point out to simplify work towards an initial
migration.
One interesting problem I expect we will have to deal with is deferring
migration of parts of the model that we are not initially looking to
support. Even if we decide to support the full model from Bloodhound
from the start, including the plugins we install by default, we can't
really be expected to be able to deal with all trac-hacks that users may
have installed. It may be possible to introduce additional plugins to
deal with particularly important trac-hack plugins that re-migrate data
from the original model. Anyway, I'm looking forward to seeing how this
will work!
Cheers,
Gary
On Mon, 18 Dec 2017, at 10:45 AM, Daniel Brownridge wrote:
> Hi Gary,
>
> Another plus one on this!
>
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> One point to note about Django is it's really good for transitioning
> from existing datamodels.
>
> See https://docs.djangoproject.com/en/2.0/howto/legacy-databases/
>
> What can work well is having a hybrid situation of existing code +
> Django looking at same database tables while bringing things up to par
> with the existing functionality. This is kind of like a double heart
> bypass approach. Auto-generate models from existing tables. Models are
> 'unmanaged' in first instance. Then build rest of Django (views, forms
> etc.) around the models. Then excise old Bloodhound / Trac code when
> things are up to scratch. The make models managed plus migrations. Then
> data model can evolve independently from that point forward. Nice point
> is it give an opportunity to keep existing data.
>
> May be more hassle than it's worth but just thought I'd throw it in the
> mix.
>
> Thanks,
>
> Daniel
>
> On 13/12/17 01:13, Gary wrote:
> > Hi everyone,
> >
> > I would like to propose that Apache Bloodhound should migrate away from
> > Trac as a base and instead use the Django web framework.
> >
> > Some of the advantages we would gain from such a move include:
> >
> > * Django supports Python 3 (as I understand it from version 2.0, Python
> > 2 support is dropped)
> > * Django is popular enough that it should be considered a good
> > transferable skill for our contributors
> > * Similarly it may be that potential contributors with Django
> > experience may be attracted to this project
> >
> > Other benefits we will have is that we will gain better control over the
> > basic data model rather than having to do any monkey patching or sql
> > translation.
> >
> > My proposal as it is does not intend to go any further than settle the
> > question of our desire to change from Trac to Django but there are
> > decisions around some of the practicalities that are worth considering.
> >
> > Given previous discussions, I suspect that we have enough support for
> > some kind of migration to Django as a base for the project. As far as I
> > am concerned there is nothing in previous discussions during the setup
> > of the Apache Bloodhound project that ties the community to Trac as a
> > base. Our only real commitment regarding our dealing with Trac was that
> > we would not encourage any kind of fork. Please do put me right if
> > anyone feels I am misrepresenting the situation of course.
> >
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> >
> > The latter extreme does still feel a bit too much like forking Trac for
> > my liking so I think we need to be careful if something like that is
> > seen as best.
> >
> > To start from scratch will leave us with plenty to do but I am hoping
> > that we will find ways to integrate other external projects to provide
> > features, either through Django apps and middleware or beyond.
> >
> > Regardless of other decisions, the scope of the project should remain
> > broadly the same, so we would be aiming to have reasonable feature
> > parity including, amongst other stuff:
> >
> > * Multi tracker support (multi-product)
> > * Integrated wiki
> > * Fast search plugin
> > * SCM integration
> >
> > We will obviously also need to ensure that we can migrate from a
> > bloodhound based on Trac to any new version.
> >
> > I look forward to hearing thoughts around this.
> >
> > Cheers,
> > Gary
>
>
