librelist archives

« back to archive

Base per-person (and per-conference-person) information

Base per-person (and per-conference-person) information

From:
Gunnar Wolf
Date:
2013-01-01 @ 22:51
Hi,

I understand the intention to keep the individual extras being added
to Frab as plugins - If the logic can be cleanly separated from the
core, it has all reason to be kept separate. However, I am unsure on
how to start doing the changes (without becoming a PITA) for the
DebConf installation we will use.

Due to the nature of every conference, we will have to add many
fields, both to the Person and to the ConferencePerson tables. Things
such as the T-shirt size, food preferences, lodging preferences, and a
long etcetera that I don't have handy (I know I did a list of needed
fields, but I left it at home... 7000Km away right now).

So... Well, how should we approach this? I notice the fields are all
explicitly (hard-wiredly) handled. I have done my share of Rails
development, but have not done much in the last year or so - Certainly
not under the 3.x series, and there are many changes for me to
re-learn. Still, I did a plugin to help cope with changing DB schemas
that could be interesting - And I later learnt that "Dr. Nic" did
basically the same, even with a very similar name, and probably in a
cleaner fashion:

http://magicmodel.rubyforge.org/
http://magicmodels.rubyforge.org/dr_nic_magic_models/

How would you feel about making those (very important!) tables act
magically, so we can define extra fields and just use them? Or am I
being too blunt about something?

Greetings,

Re: [frab] Base per-person (and per-conference-person) information

From:
Mario Manno
Date:
2013-01-02 @ 00:21
Hi Gunnar,

I'll try to comment as best as I can.

> I understand the intention to keep the individual extras being added
> to Frab as plugins - If the logic can be cleanly separated from the
> core, it has all reason to be kept separate. However, I am unsure on
> how to start doing the changes (without becoming a PITA) for the
> DebConf installation we will use.

Well, we're looking forward to your input. (I'll probably go on and
implement solr/resque next, because I want to get rid of acts_as_indexed
for the sortable/filterable tables.)

A plug-in system has been discussed in:
 
https://github.com/frab/frab/issues/10
https://github.com/katastrophie/frab/issues/58

There's also the engine branch, which contains some related changes, we
could try to extract these and go from there.

> Due to the nature of every conference, we will have to add many
> fields, both to the Person and to the ConferencePerson tables. Things
> such as the T-shirt size, food preferences, lodging preferences, and a
> long etcetera that I don't have handy (I know I did a list of needed
> fields, but I left it at home... 7000Km away right now).

Some of these would make nice add-ons. Btw, the 29c3 handles T-shirts in
presale system. All of these values probably belong into event person,
as they may vary with every event.

If we had a plug-in system I'd suggest to create a "conference_visitor"
plug-in. Since the debconf creates accounts for every visitor it is
quite different from other conferences, which only use frab to manage
talks.

> http://magicmodel.rubyforge.org/
> http://magicmodels.rubyforge.org/dr_nic_magic_models/
> 
> How would you feel about making those (very important!) tables act
> magically, so we can define extra fields and just use them? Or am I
> being too blunt about something?

I took a quick look at these gems and I'm not convinced :)
I like the explicit way of dealing with relations in the model. And we
need to declare options like ':dependent => :destroy' on these
relations.

But then we still have a problem with extension that need to be listed
as a relation in another model. For example, the ticket plug-in would
need to add "has_one :ticket_server, :dependent => :destroy" to the
conference model.


cheers,
mario

Re: [frab] Base per-person (and per-conference-person) information

From:
David Roetzel
Date:
2013-01-02 @ 09:59
Hi,

> But then we still have a problem with extension that need to be listed
> as a relation in another model. For example, the ticket plug-in would
> need to add "has_one :ticket_server, :dependent => :destroy" to the
> conference model.

this is no problem at all. Due to the open nature of ruby's class
system, plugins can easily make those kinds of additions to exisiting
classes.

Kind regards

David

Re: fulltext search (was Base per-person (and per-conference-person) information))

From:
David Roetzel
Date:
2013-01-02 @ 10:07
Hi,

> Well, we're looking forward to your input. (I'll probably go on and
> implement solr/resque next, because I want to get rid of acts_as_indexed
> for the sortable/filterable tables.)

why do you want to get rid of acts_as_indexed? Have you hit one of its
limitations or experienced any bugs?

I originally chose aai to avoid additional dependencies. I can see how
large scale installations like CCC's would profit from a "proper"
search engine, but I did not want to burden everyone with having to
setup and maintain an additional service like solr.

(Also keep in mind, that plugins like sunspot make it ridiculously easy
to use solr in a development environment, but they do not help much
with setting up and maintaining it in production.)

If you insist on this change, you might want to have a look at
elasticsearch as a more modern and web-focused alternative to solr. I
have no first-hand experience with it but hear good things about it.

Regards,

David

Re: [frab] Re: fulltext search (was Base per-person (and per-conference-person) information))

From:
Mario Manno
Date:
2013-01-11 @ 09:36
Hi,

On Mi, 2013-01-02 at 11:07 +0100, David Roetzel wrote:

> why do you want to get rid of acts_as_indexed? Have you hit one of its
> limitations or experienced any bugs?

Thanks to your comments I took the time to read more about aai and to
clean up all the tables. I think it's working fine now.

Also there is a aai tmp/index directory which needs to be deleted from
time to time.

solr might speed things up, but it sure is a  huge dependency and I
think we'd need chef scripts to keep everything clean and installable.