database migration questions

Piotr Przybył piotr at
Tue Aug 23 23:10:34 CEST 2016

On 23/08/16 19:26, Jaromir Talir wrote:
> On Tue, 2016-08-23 at 16:23 +0200, Piotr Przybył wrote:
>> Hello cz.nic Team
>> I have a few questions related to database migration of FRED if you
>> don't mind.
>> ====
>> When trying to download the latest sources from
>> age/2904/download/#source I've
>> realised, that they're not available. E.g. the latest migration
>> scripts are available in
>> fred-db*deb, but the tarball is not a corresponding one.
>> Could you please try to release latest sources in tarballs?
> The last version I've uploaded on the website is 2.23. We have released
> small upgrades 2.24 and 2.25 but there is an issue with building them
> on Fedora 24 so I'v postponed next website update to 2.26 that will be
> available for recent Fedora system. I believe this will be available
> next week and I'll do website update immediately after that.

What I had in mind precisely was that the page lists e.g., which doesn't contain
notification_queue for instance. I discovered the SQL upgrade script installed by the package, but
can't see it in sources tarball.

>> ====
>> Could you briefly describe what's the purpose of tables:
>>  contact_address
>>  contact_address_history
>> As far I can tell after analysing the sources, these tables are
>> populated by a functionality called
>> from MojeID ( =your special NIC registrar to keep domain contacts
>> defined at central level, not each
>> registrar's level).
> There is a concept of single address in FRED. In our mojeID registrar
> we have a concept of multiple addresses (mail address, permanent
> address,...). We decided to move this concept down into FRED and
> implemented multiple addresses in FRED database. The next step was
> supposed to be propagate this multiple address manipulation into EPP
> but this was postponed for a while. I believe we will get to his soon.

I believe this can make a fair usage in case of a registrar. E.g. you create an invoice with address
A, print it and mail to address B. However, I'm not convinced that this makes sense in case of a
registry which sends nothing at all and the only address is supposed to be "the legal address". I
understand your situation and efforts with MojeId, I'm only wondering if other registries will
utilise that. (Although 1 is still a valid case of having N choices.)

When it comes to changes addresses it might be nice for some to make the street not obligatory
field, because there are countries in which the street address can be missing and it's perfectly
fine. ;-)
>> ====
>> What are the following tables for? Or: How the checks of contacts are
>> working? Is is something
>> related to checking if a contact's address fields are valid?
>>  contact_check
>>  contact_check_history
>>  contact_check_message_map
>>  contact_check_object_state_request_map
>>  contact_check_poll_message_map
>>  contact_test_result
>>  contact_test_result_history
>>  contact_testsuite_map
>>  enum_contact_check_status
>>  enum_contact_check_status_localization
>>  enum_contact_test
>>  enum_contact_test_localization
>>  enum_contact_test_status
>>  enum_contact_test_status_localization
>>  enum_contact_testsuite
>>  enum_contact_testsuite_localization
> That would be loooong explanation :) I believe this will be part of new
> documentation that Lena is working on. I talked about this briefly
> during ICANN Techday 
> slide 12,13
> (selective contact validation). 

So my guess that this is for contact/address validation was right. ;-)
I'm not aware of the law you must obey/implement in your system.
This seems to be like a policy forcing every contact to be nice and valid for all domains, even if
they're not causing any trouble (like having sites which might be illegal in any part) and BEFORE
they cause trouble.
Are you forced to do that? Maybe you're not allowed to assume that each registrant/admin is honest
and peaceful "until proven guilty", or even "accused"?

>> ====
>> There's a table notification_queue. I can't find any usage of it
>> (maybe because not all tarballs are
>> up to date). What is it for?
> I was going to mention this in mail summarizing changes in FRED-2.24,
> 2.25 and 2.26. There is a new concept of asynchronous notification in
> FRED-2.25. In previous versions when registrar issued EPP command that
> involved sending notification email to registrant, EPP command was
> waiting for notification subsystem to create this email. Asynchronous
> notification means that there is only small record in
> notification_queue table that notification should be send and
> asynchronous script will create this email in separate process. The
> advantage is greater speed of EPP and stability because when subsystem
> for notification email creation is not available EPP is not locked.

Oh yes, this makes a perfect sense.

>> Do you replicate this table using Slony? (Because it has neither
>> primary nor unique key.)
> We are not using Slony anymore, we have changed to internal streaming
> replication about 4 years ago. Maybe that's why we missed to add
> primary key. I'll ask my colleagues to add this primary key.

Thank you for your answers.

Best regards

More information about the fred-users mailing list