in reply to Migrating Perl to Java or .NET

Since all of your data is in a mysql database, you could write stuff in java that will manipulate that data and perl will see the changes as well.

Of course, it is highly recommended that you not do this, because now instead of having your app split into 3 pieces (web, perl, and mysql) you have 4, or possibly 6 depending on how you look at it. (web, perl, mysql, and java) or (web, perl, mysql) and (web, java, mysql), meaning that you will be duplicating logic. This gets messy when a new requirement is added for a field, then you have to update it in both places.

If you must do this, consider converting the perl code to java or whatever as needed (screen at a time or functional units), and THROW THE PERL AWAY. There should never be 2 ways of doing the same thing, either one codebase or the other should be handling it.

Replies are listed 'Best First'.
Re^2: Migrating Perl to Java or .NET
by Jason Hollman (Novice) on Mar 24, 2005 at 17:24 UTC
    I should clarify...

    Yes, I certainly don't want to dubplicate code. There are many modules (here "module" means functional subsystem from the user's perspective). E.g. imagine 6 different people see the tickets and do different things with them. They each get a slightly different view and focus on different parts of the ticket data. 3 modules are done in Perl. We would want to do modules 4-6 in Java or .NET and then go back and one at a time convert modules 1, 2, and 3 to the same technology.

    It sounds like this is doable as long as all state is maintained in the database, right? We do maintain session state while fields are being modified, but as long as no two people access the same ticket at the same time it should be ok; even then it's just the usual data concurrency/overwriting issues, and won't cause any type of server state inconsistency (as opposed to potential data inconsistency).

    --Jason

[reply]
      Keeping all data (including state) in the DB allows you to develop manipulation programs in whatever language you like. Concurrency will be handled by the MySql server process, so it won't be an issue to you for what server state consistency is concerned.

      As for data consistency, you really have to dig into your code looking and take countermeasures regarding possible critical races in UPDATEs. This could be achieved with a custom "locking" mechanism (via an added column, for example), but understand that a lock by a program which is about to die makes the locked data "read-only" virtually forever. Another quick solution would be replacing UPDATEs with REPLACEs.

      Flavio

      Don't fool yourself.
[reply]

In Section Seekers of Perl Wisdom