Nservicebus: Databus properties are not supported for fields lists and subproperties

Created on 29 Aug 2012  Â·  29Comments  Â·  Source: Particular/NServiceBus

Detect this on scanning and throw a good exception

Workaround

The current workaround is to skip the databus and design the message contract to only pass links to the big properties. Essentially mimicking what the databus is doing

Bug

All 29 comments

@andreasohlund considering the perf implications of doing this and the fact that no one has complained about this for two years wouldnt this be better to just leave as-is and document the behaviour. perhaps on initial scanning throw an error if the unsupported cases are discovered??

that makes sense, description and title updates

@jkodroff we'll triage this one and see if we can give any ETA's

Since encryption supports nested props, I think we should support it for DataBus as well.

+1

On Tue, Jun 17, 2014 at 9:05 AM, John Simons [email protected]
wrote:

Since encryption supports nested props, I think we should support it for
DataBus as well.

—
Reply to this email directly or view it on GitHub
https://github.com/Particular/NServiceBus/issues/626#issuecomment-46273885
.

The current workaround is to skip the databus and design the message contract to only pass links to the big properties. Essentially mimicking what the databus is doing

I just flattened my messages so an email can only include 1 attachment,
which is all my client uses at the moment, so this is not a super-critical
issue for me. That said, I do think it should still be fixed.

On Tue, Jun 17, 2014 at 3:09 AM, Andreas Öhlund [email protected]
wrote:

The current workaround is to skip the databus and design the message
contract to only pass links to the big properties. Essentially mimicking
what the databus is doing

—
Reply to this email directly or view it on GitHub
https://github.com/Particular/NServiceBus/issues/626#issuecomment-46274193
.

After triage we've decided this to not treat this as a urgent issue since there is a workaround. Added to backlog.

@jkodroff not the answer you where hoping for and I'm sorry for that

Nah, it's cool - I just limited my emails to a single attachment, which
meets my current requirements.

On Tue, Aug 19, 2014 at 3:47 AM, Andreas Öhlund [email protected]
wrote:

After triage we've decided this to not treat this as a urgent issue since
there is a workaround. Added to backlog.

@jkodroff https://github.com/jkodroff not the answer you where hoping
for and I'm sorry for that

—
Reply to this email directly or view it on GitHub
https://github.com/Particular/NServiceBus/issues/626#issuecomment-52600571
.

I think this should be fixed. The only documentation I've found it the code sample and it says nothing about the DataBusProperty needing to be a top level property. I have wasted time trying to get this to work only to find it is a known issue.

Our data response message uses a generic interface designed around only returning dtos to the web so it will not be trivial to rework.

The workaround seems to be to create our own databus feature.

@MaggiePlusPlus - I'll bring this up again based on your comment, but in the meanwhile we'll fix the documentation to address this. Thanks for bringing this up.

Thank you. If It can exist on the dto level I can clean up a lot of code in another part of the app.

Is the DataBaseProperty supposed to work in a response message? I am not getting this to work either.

@MaggiePlusPlus regarding:

Is the DataBaseProperty supposed to work in a response message?

Yes, it works, what issue are you having?
What version of NServiceBus are you running?

Triage:

  • Improve exception

In order for us to figure out if we need to throw an exception or not, we would have to walk fields and nested object props.
So if we go that extra mile to scan deep fields + nested object props we may as well support Databus properties in fields and nested object props.

@andreasohlund thoughts?

@johnsimons - my 2 cents is that we should. And we document that nested properties will incur performance cost (if we find that there is significant cost).

How bad would it be to let customers choose if they want nested properties to be scanned or not through explicit setting on config.UserDataBus<T>().ScanNestedProperties()?

-1 on that. That's exposing implementation details. Also, what if I don't set, then we don't scan and the user is in the same trouble? And there will be some confusion for someone whether they need to or not. What if they add a nested prop at a later stage? I think, If we do it, we do it right, otherwise we throw an exception. The user shouldn't have to choose for us to scan or not.

We are on 4.2, I was not able to get the databus on the response. I ended up reworking the code so we process the data on the web server and not use the bus.

@Particular/nservicebus should we do it or not ?

Since this is not a critical issue and there are workarounds, I'm closing it.
If you feel strong about it please reopen it.

Is this issue still open or prioritized?

I'm running into same issue with a type in List!

thanks

I have this same issue as well. Sending a command with a collection of emails with a collection of attachments. Seems odd that this is not supported. Also, it doesn't look like the documentation is updated as it does not mention anything about nested properties?

Same here and I could use your advice. Has this bug been scheduled yet, or is it better to implement a workaround?

@DannyvanderKraan Not to speak for the NSB team, but if I ran into this issue a couple of years ago and it still hasn't been fixed, I would just go with the workaround.

@jkodroff Work has commenced on the workaround, don't worry. ;) But this issue is tagged for scheduling nov 28 2014. Well that is not even that long ago if you look at some of the other issues. And I personally think it would be a great addition.

The DataBus property restriction to be top level property is still not documented 👎

Hi @peef, clearly the ball got dropped on this one.

I just amended the documentation here:

https://docs.particular.net/nservicebus/messaging/databus/#specifying-data-bus-properties

Was this page helpful?
0 / 5 - 0 ratings