Wednesday, April 23, 2008

Memcache Trick

i was faced with a very weird behaviour while working with memcache-client with two memcache servers

first lets look of my configuration to the client in order to explain on it
On my first server

memcache_options = {
((some options)
CACHE = memcache_options
CACHE.servers = [((SERVER1)), ((SERVER2))]

On my second server

memcache_options = {
((some options)
CACHE = memcache_options
CACHE.servers = [((SERVER2)), ((SERVER1))]

after running both servers, i noticed that what i enter in memcache on that server isn't available to the other server

Where is the problem??

here it is, a very strange reason

CACHE.servers = [((SERVER2)), ((SERVER1))]
CACHE.servers = [((SERVER1)), ((SERVER2))]

this is the problem, one uses SERVER1 then SERVER2
other uses SERVER2 then SERVER1

i thought that memcache client when checking for a key, he looks at the first, if not found then looks at the second then say it is a miss
but i realized that if it isn't on the first then it doesn't look at the second

That's it, just take care, cuz small things can waste your time and energy looking after their reasons

Adding Data Through Migrations

one of the points i am always faced with while adding some migrations, is my need to add some system data as a static group for Administrators or any other.

so simply i create a new migration and add the following

and it simply works fine, until someone later one adds a new column
in another new migration and adds validation on that column in the Model

and here the problem occurs
my old migration throws exception because of validation added on a new column added later in another migration but Model carries code validating it

how to solve these problems?

i suggest not using create at all
but rather use new and set our attributes
then save without validations

Thursday, April 3, 2008

Thick Models Thin Controllers

i have worked for about six months with Rails and through this time i was coding a lot in my controller which has shown to me lots of problem later on

for example,

i was having a Topic model and Post model, where every topic has many posts
and in each of these two models there is a field called archive

i was having a controller that changes the archive field to a certain value then pass on every post it owns and change its attribute also

later on, i made another controller and in it i also changed that field in it and passed on all posts to do the same change in it

this led to redundancy and duplication of code

but the problem became more complicated when i wanted to change the logic of this topic and its posts replication to a new way

here i have to move on my controllers and change this code in them

but i have added the code that observe this change in topic attribute and apply it on all its posts inside the model, i would haven't faced this problem anymore
and this will give me flexibility to do changes easily also

so this led to the idea of having my controller thin containing the least amount of code and my model thick containing large amount of code