How to deal with commands with large blob ?

14 views
Skip to first unread message

Steve B

unread,
Aug 30, 2011, 8:17:13 AM8/30/11
to ncqrs-dev
Hello,

I'm new to NCqrs and my question may be obvious... sorry.


How to deal with large blob when commanding ? A good example can be a
file upload on a web site. Imagine I have a "bug report" web site that
allows to submit bugs with attachments. My GUI is a form with standard
bug submission fields (how, where, steps, etc.) and a collection of
files uploaded.

Do I have to add a list of FileData to my command ?

thx

@marcofranssen

unread,
Aug 30, 2011, 9:15:22 AM8/30/11
to ncqrs-dev
I should make an envelope for it. You can implement some serialization
and deserialization logic in here. You domain can then unfold this
envelope and do the things needed.

Greg Young

unread,
Aug 30, 2011, 9:26:17 AM8/30/11
to ncqr...@googlegroups.com
if they can really be big consider storing the data in a document db
etc and passing a link with the command.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

Steve B

unread,
Aug 30, 2011, 9:30:22 AM8/30/11
to ncqrs-dev
So you suggesting me to write the file to a separate DB, then simply
passing the link to the file as command argument ?
Does it mean that the file save is taking place out of the ncqrs
framework ?



On 30 août, 15:26, Greg Young <gregoryyou...@gmail.com> wrote:
> if they can really be big consider storing the data in a document db
> etc and passing a link with the command.
>

Greg Young

unread,
Aug 30, 2011, 9:32:10 AM8/30/11
to ncqr...@googlegroups.com
If the documents can be very large (imagine a 100 mb message :)), yes
this is a good option.

Pieter Joost van de Sande

unread,
Aug 31, 2011, 4:45:10 AM8/31/11
to ncqr...@googlegroups.com
Yeah, as long as you include a reference to storage entry this is a good option. This prevent large messages. Also it could be that most handlers won't be interested in the actual content. If true, it is a waste to send the full content.

thang chung

unread,
Aug 31, 2011, 10:48:59 AM8/31/11
to ncqr...@googlegroups.com
Write a file to database look like not a best practice, instead of we can using DFS for storing a file, and database only keep the link to this file on DFS. IMHO.
--
==========================================================
Regards,
ThangChung,
http://weblogs.asp.net/thangchung

Greg Young

unread,
Aug 31, 2011, 10:50:59 AM8/31/11
to ncqr...@googlegroups.com
a document database not a relational database

--

Steve B

unread,
Sep 1, 2011, 8:42:32 AM9/1/11
to ncqrs-dev
Actually, my target is to leverage MongoDB GridFS... as hosting
mongoDB is cheaper on linux OS, I'm willing to rely on OS proprietary
FS replication.

steve

On 31 août, 16:48, thang chung <chungquangth...@gmail.com> wrote:
> Write a file to database look like not a best practice, instead of we can
> using DFS for storing a file, and database only keep the link to this file
> on DFS. IMHO.
>
> On Wed, Aug 31, 2011 at 9:45 AM, Pieter Joost van de Sande <p...@born2code.net
>
> > wrote:
> > Yeah, as long as you include a reference to storage entry this is a good
> > option. This prevent large messages. Also it could be that most handlers
> > won't be interested in the actual content. If true, it is a waste to send
> > the full content.
>
Reply all
Reply to author
Forward
0 new messages