Bug: <PostGres>

[rubenalves]

I have this Code:

[Map("Utilizador_ID")]
public Guid UtilizadorID { get; set; }

It Works in MsSql server but in PostGresSQL ir gives the error

[rubenalves]

The error is that there does not exist the column Utilizador_ID

[mikependon]

Can you share the exact error you are encountering?

[rubenalves]

I have gave up on PostGres. By the way how can i map to a readonly property that is a calculated column in sql server?

[mikependon]

Does the information in our limitation page answer your question? It is only supported for reading, not writing.

Link: https://github.com/mikependon/RepoDb/blob/master/RepoDb.Docs/limitations.md#computed-columns

[rubenalves]

It responds to my question.
I resolved my problem using stored procedures.

Very bad decision on RepoDB side to remove the IgnoreAttribute or something like Dapper
[Map(read-only)] - something like this.
public deciaml Saldo{ get; set; }

Thanks.

All those Issues not Closed makes the project look dead or abandoned.

[cajuncoding]

Yeah I wish RepoDb had an ignore attribute, but it does allow you to explicitly specify the fields which we use to implement our own ignore attribute logic in our repository layer…

We manually filtering out properties that are ignored and for valid properties we look up any Map attributes if defined and caching final DB fields ourselves for performance.

[mikependon]

Hey, sure, we can resume the IgnoreAttribute on the library if this is really necessary.

[rubenalves]

I think that a option like

[Computed]
public decimal Balance { get; set; }

or

[ReadOnly]
public decimal Balance { get; set; }

world be easy to impletent and ignore on update or insert comand and it wold make much more sence to the users of the library.

[cajuncoding]

[ReadOnly] wouldn’t make as much sense and not all field use cases are “Computed” … other libraries use [Transient] but I’ve never been a big fan as it’s a bit abstract…

[cajuncoding]

@mikependon yes there are use cases where the automatic behavior used by RepoDb isn’t suitable… we have legacy models (horribly designed that we inherited) that had naming conflicts with underlying tables but we couldn’t change the names due to tight coupling with the front end, etc.

So by applying our own field filtering and generating our own list of field names we alleviated this allowing us to migrate from the old (really bad & proprietary) ORM to RepoDb.

[mikependon]

I understand the intent and I also agreed that 2 separate attributes might be overkill. I am initially thinking of just reverting the IgnoreAttribute...

public class Class
{
   ...
   [Ignore(Direction.<Both|In|Out>]
   public string Field { get; set; }
   ...
}

and also support it on FluentMapper.

FluentMapper.Entity<Class>().Ignore(e => e.Field, Direction.<Both/In/Out>)

In which the Direction.<Both|In|Out> signifies to which operation it is being ignored (In = all types of reads, Out = Delete, Update, Create).

Thoughts?

[rubenalves]

I think that his way solves all problems.
looks good.

[cajuncoding]

For an Attribute it works fine. But to be honest the In/Out semantics are a bit esoteric and not nearly as clear as Read/Write (for Delete, Create/Insert, Update) semantics for the enum would be.

But in any case the default should be Both or Ignore.ReadAndWrite to simplify the most common use case.

So personally I think the following would be more intuitive for most:

public class Class
{
   ...
   [Ignore(IgnoreMode.<ReadAndWrite|Read|Write>]
   public string Field { get; set; }
   ...
}

[mikependon]

@cajuncoding your comments and naming convention proposal make sense. It is good to go with that.