CodeIgniter Forums
File Log - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forum-20.html)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forum-23.html)
+--- Thread: File Log (/thread-57653.html)



File Log - El Forum - 03-31-2013

[eluser]haris244808[/eluser]
Hi there...
I have files(some data) inserted in db... (ex: user can create a subject and content and they are inserted in database). Then the user can send created file to other users...

now i want to track the movement of every file created...ex(when created, who created, when it was send, to whom it was send, etc)... then when i click to a button "file log" to display me all the details of that file

so my question is that...which is the best way to achieve this....is it better to store all the data in database...or create .txt file for every file and store data to that file...or to use hooks...etc?

what do you prefer??


File Log - El Forum - 03-31-2013

[eluser]TheFuzzy0ne[/eluser]
I think logging to the database would make much more sense. It would give you a lot more control over the data you could retrieve. For example, you'd be able to answer the following questions:

What files were created yesterday?
How many files were sent 7 days ago.
Who has created the most files?
Who has received the most files?

And the list goes on... I'm pretty sure you wouldn't be able to do that with plain text files.

Now, when a file is uploaded, the date of creation is stored in the database along with the file information. You could do with another table which tracks the movements. Every time it's sent to someone, add a row. You table would probably need to be something like this:

| file_id | sender_id | recipient_id | sent_on |

You might need to add more columns, but with that, you can index every column, and join the table to the other relevant tables.


File Log - El Forum - 03-31-2013

[eluser]haris244808[/eluser]
[quote author="TheFuzzy0ne" date="1364729894"]I think logging to the database would make much more sense. It would give you a lot more control over the data you could retrieve. For example, you'd be able to answer the following questions:

What files were created yesterday?
How many files were sent 7 days ago.
Who has created the most files?
Who has received the most files?

And the list goes on... I'm pretty sure you wouldn't be able to do that with plain text files.

Now, when a file is uploaded, the date of creation is stored in the database along with the file information. You could do with another table which tracks the movements. Every time it's sent to someone, add a row. You table would probably need to be something like this:

| file_id | sender_id | recipient_id | sent_on |

You might need to add more columns, but with that, you can index every column, and join the table to the other relevant tables.[/quote]

when u say "add new row"...u mean to insert the data and not to update it??

ex: User1(with id=1) creates a data and sends to User2(with id=2) ... now user2 modifies the data and sends it to user3..
Now when i click the log button of this file i want to show:
User1 created the file (date when was created)
User1 Sent fileSadfilename) to USer2 (date when was sent)
User2 Edit file(filename) (date when was edited)
User 2 sent file:filename to user3 ((date when was sent))

so here i have to vreate a table 'log' an whenever smth happens to insert a new data(row) to table??



File Log - El Forum - 03-31-2013

[eluser]TheFuzzy0ne[/eluser]
Why would you want to update it? You want a file "log", right? That means trackable history. I've never seen any kind of logging mechanism that "updates" logged lines. They simply append the the log, and the log grows.

If you structure your table as I suggested, that will be a lot more robust than plain text logging. You can take that approach if you want, but if you want more flexibility, my way would be a much better alternative.


File Log - El Forum - 03-31-2013

[eluser]haris244808[/eluser]
[quote author="TheFuzzy0ne" date="1364745771"]Why would you want to update it? You want a file "log", right? That means trackable history. I've never seen any kind of logging mechanism that "updates" logged lines. They simply append the the log, and the log grows.

If you structure your table as I suggested, that will be a lot more robust than plain text logging. You can take that approach if you want, but if you want more flexibility, my way would be a much better alternative.[/quote]

ok so as you explained: file_id will be the foreign key?
and whenever smth happens to that file...i need to insert a new row with new(sender_id,etc...except file_id which will be same)
(see movement example with 3 users that i wrote before)...Am i able to achieve that??


File Log - El Forum - 03-31-2013

[eluser]TheFuzzy0ne[/eluser]
Yes, although you'd have 3 foreign keys. File ID, Sender ID and Recipient ID.

If a file already exists, you should have the creation date and creator ID in the file table itself, so there's no need to log that. All this table is for, is for tracking a file after it's creation.


File Log - El Forum - 03-31-2013

[eluser]haris244808[/eluser]
[quote author="TheFuzzy0ne" date="1364746688"]Yes, although you'd have 3 foreign keys. File ID, Sender ID and Recipient ID.

If a file already exists, you should have the creation date and creator ID in the file table itself, so there's no need to log that. All this table is for, is for tracking a file after it's creation.[/quote]

ok thank you...


File Log - El Forum - 03-31-2013

[eluser]haris244808[/eluser]
Ok another question...
can i achieve what i want by nabling MYSQL Query Log? are you familiar with that?

Here is a link of usage example


File Log - El Forum - 04-01-2013

[eluser]TheFuzzy0ne[/eluser]
Perhaps, but you'd have an overhead of parsing the logs.

By putting it in a database, you'll probably have less file IO, plus you can find pretty much anything you need in mere milliseconds with the right query, (so long as your tables are indexed correctly).