Feature Request: Invisible collections

[JimBobSquarePants]

I'd like to be able to add collections to the configuration that do not show up in the tree view.

This would allow the querying of tables that do not require CMS editing.

For example if I have a table that is used simply as a lookup, or enumeration representation - something like Australian States and Territories.

I don't need it to appear in the CMS but I want to be able to query it for reporting.

[mattbrailsford]

Can you expand on the use case? I understand the feature, but not how you'd use it. ATM you could create your own repository to access the table and "just" bypass fluidity all together, I'd just like to understand what going through Fluidity would bring?

[JimBobSquarePants]

It looks to me, reading the API like creating a custom repository is a lot of work. All or nothing with no incremental overrides. I want to avoid that. Am I wrong?

[mattbrailsford]

You only need to inherit the fluidity base repository if you want it to be managed via fluidity. If you just want to access it yourself in your own code, you can create your own lightweight repository.

[JimBobSquarePants]

You mean inherit FluidityRepository<TEntity, TId>?

https://umco.github.io/umbraco-fluidity/api/repositories/

If so this is exactly what I'm trying to avoid. Inheriting that class means having to implement the abstract XXXImpl methods and I have zero idea what to put in them.

[mattbrailsford]

Yea, but I'm saying, you only need to do that if you want your entity to be known and managed by Fluidity. If you don't, and you just want to access data in a database table, then create your own repository class that does whatever you want.

[JimBobSquarePants]

What I want is the convenience an consistency that the data access API offers without having to have individuals navigating through various relevant trees interspersed with trees that are meaningless to them. When I implement that class I get nothing other than a bunch of NotImplementedException's.

I'm dealing with types that are related to (via foreign keys) types Fluidity knows about and it seems very odd to me to have to implement something from scratch to work with two related types.

There's an assumption here that myself and others know how to implement the methods. Fluidity is an attractive option because I don't need to know the nuances of PetaPoco with the various extensions Umbraco have added.

[mattbrailsford]

Sure, but the responsibility of Fluidity isn't to make creating ANY repository easy, it's only job is to make editing custom data tables easier.

Can you provide me a code example of something you want to be able to do? As I'm just not getting why creating your own NON Fluidity repository is a problem.

[JimBobSquarePants]

I'm just not getting why creating your own NON Fluidity repository is a problem.

Because I simply don't know how to. I don't know what to put into any of the XXXImpl methods, I don't know how to use PetaPoco, and I don't particularly write SQL well.

Ok. Here's the exact scenario.

I have a custom customer table that editors can view/edit through Umbraco using Fluidity

dbCustomer Id Email Hash (A hash of the email address) Name

I generate links based on that hash but I need to make the link expire after a certain time.

An obvious solution is to create a related table

dbTemporalHash Id CustomerId (foreign key) Hash (same as customer hash, duplicated for performance) ExpiresDate

Using this I can now create a temporal hash related to a customer which I can check against in my code to see if the hash has expired.

Now, I don't need or want the editor to be able to see the data stored in that table so I cannot create a tree item for it. However I want to be able to do something like

Fluidity.Fluidity.GetRepository<TemporalHash, int>

Which is impossible since in order for this to work I have to register a complete config which means adding a tree item to the backoffice.

If there was a way to register a class without the full configuration and backoffice visibilty then this would be easy.

Does this make it more clear?

[mattbrailsford]

Thanks for clarifying. I do now understand what you are asking for but IMO this is outside of the scope of what Fluidity is for. It isn't to simplify your data access layer or to prevent you from needing to learn PetaPoco, it's simply to make building a UI for your custom models easier.

In the spirit of being helpful though, I'll offer you an example of how you should go about making your custom repository.

So, given the table you outlined before, I'll assume a Model like so

[TableName("dbTemporalHash")]
public class TemporalHash
{
    public int Id { get; set; }
    public int CustomerId { get; set; }
    public string Hash { get; set; }
    public DateTime ExpiresDate { get; set; }
}

With this, you could define a simple repository like so

public class TemporalHashRepository
{
    protected Database Db => ApplicationContext.Current.DatabaseContext.Database;

    public virtual void Save(TemporalHash entity)
    {
        Db.Save(entity);
    }

    public virtual void Delete(TemporalHash entity)
    {
        Db.Delete(entity);
    }

    public virtual TemporalHash GeByCustomerId(int customerId)
    {
        return Db.SingleOrDefault<TemporalHash>("SELECT * FROM [dbTemporalHash] WHERE [CustomerId] = @0", customerId);
    }
}

And then you can access your data with

var customerHash = new TemporalHashRepository().GetByCustomerId(customerId);

As I say, because Fluidity isn't managing this table, there is no need for the repository to inherit from the ase class and so you can create just the methods you need.

[JimBobSquarePants]

Was worth a try 😛

Thanks for the code sample I really, really appreciate it! 👍