Re: [Tracker] is data-type of each field (metadata) stored in database is configurable?

[Jackson Lawson <jacksonlawson55 yahoo com>]

----- Original Message ----
From: Martyn Russell <martyn lanedo com>
To: Jackson Lawson <jacksonlawson55 yahoo com>
Cc: tracker-list gnome org
Sent: Thu, June 3, 2010 2:06:53 AM
Subject: Re: [Tracker] is data-type of each field (metadata) stored in database is configurable?

On 02/06/10 18:02, Jackson Lawson wrote:
> i have given just one scenario.. but there many instances where i
> would have to change the datatype of which tracker is maintaining in
> sqlite, to control the storage constraints..

> > don't see the use case for this, can you tell me why this should be necessary?

because i have limited storage space, i.e., upto 700 mb; hence i am looking to optimize, if possible, some of 
the field stored in database; 
for e.g., internally in database , tracker store ID as integer which i think would occupy 8 bytes, and due
to limited space, i want it to occupy 4 bytes only...

> I only need to index media files and tracker is creating table for
> all supported formats(radio,email,im,...), so m looking forward for a
> way to remove the unsupported formats&  update the existing media
> datatype to use tracker in low memory as effficient as possible...

> > Well, you can decide to not ship some of the ontologies, but you do so at your peril :)
> > The extra tables have NO data in them until they're populated so the extra _disk space_ is pretty 
> > > > insignificant. Also, this is not _memory_ we're talking about.

Agree. but still think if appl. is not utilizing other ontologies then its better to have the customization 
to configure the appl. to remove unsupported ontologies (from sqlite database) & other dependent libraries or 
modules to have the small memory-footprint & doing my best to customize tracker efficiently according to 
needs :)

-- Regards,
Martyn