CliRefresher alternative

Posts   
 
    
Posts: 5
Joined: 20-Sep-2010
# Posted on: 14-Sep-2017 11:11:12   

Hi mates,

we currently updated from 3.5 to 5.2.2. We're using LLBLGen Framework for our DataAccess.

We used CliRefresher and CliGenerator for a full automatical update of our DAL.

Workflow:

  1. Doing changes in sqlproj via Visual Studio
  2. Generating .DacPac
  3. Executing dacpac against Database
  4. CliRefresh for getting new DB model from updated database
  5. CliGenertor for generating new DAL.

Now you have cancelled CliRefresher. Is there another possibility to get an automatical update for the DAL?

Regards

David

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 14-Sep-2017 17:07:25   

Not at the moment, no.

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 21-Feb-2018 23:01:24   

This is a serious bummer. I too use the CliRefresher. I remember you mentioning this a while back, but just prayed it wouldn't really end up that way.

Using the 5.0 trial and at first I was doing the same repetitive thing, but finally had enough of it, copied my batch file from another project but, I find out it's true, no more clirefresher.

I hope you seriously reconsider giving those of us that are database first a way to quickly regenerate.

For now, I have to rollback to 4.2

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 22-Feb-2018 09:50:00   

Noted. simple_smile The main problem we have to overcome is that 'sync' is really a more broader activity than what it used to be. Though I understand that with database first oriented projects you only refresh anyway so it's not a big of a deal.

We'll think about it.

Btw, is using the designer such a burden ? It's a couple of clicks and you've refreshed the data, can correct errors etc. I don't see why one would revert back to v4.2 (which has a lot of downsides regarding database first, as it always wants to update the model and won't proceed if there's an error which might be corrected in the database) and not get bugfixes vs use v5, much faster runtime, way less memory consumption etc.... not to mention the other improvements we've made and are coming in v5.4... just because a couple of seconds were needed to run a tool disappointed

Mind you: database syncs might look like they always succeed but that's not the case. THere are many cases where things end up in a state where you have to decide what to do, because an error occurred and you have to pick one of 2 options, or things ended up unmapped.

IF we bring it back, it will sync 1 database database-first, won't perform validation (as that's not done in the designer as well, as errors can now be recovered by fetching new meta-data which isn't the case in v4), and can leave the project in an erroneous state so run into an error during validation when you generate code through cligenerator, and not because we messed up and introduce bugs in the data persisted to the project file, but because due to the meta-data update the entity model needs an update for which there are multiple choices and we can't make the choice for you. So in other words: it won't save you much time.

Nevertheless, we'll see what we can do. To make your life easier in the meantime: you can specify a project file as an argument for the designer exe so it will load it at startup. Then press F5 to sync it, then alt-r to run the sync tasks.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 23-Feb-2018 14:04:38   

We now have:

LLBLGen Pro Command line Sync With Database tool v5.4.0 (c)2002-2018 Solutions Design bv. https://www.llblgen.com Syncs the project with the relational model data of one database on the command line. Initializing... Initialization complete. Loading project 'c:\temp\LLBLGenProjects\NorthwindTut.llblgenproj' Project 'NorthwindTut' loaded successfully from file 'c:\temp\LLBLGenProjects\NorthwindTut.llblgenproj'. Creating backup file for project... Backup file 'c:\temp\LLBLGenProjects\NorthwindTut20180223140031.llblgenproj' created successfully. Testing connection... Testing connection succeeded. Determining elements to retrieve from target database... Elements to retrieve determined. Populating the following catalogs / schemas for database 'SQL Server': - Catalog name: Northwind Schema name: dbo

Performing sync...

Number of tasks to finish: 5 Starting task 'Retrieving all User Defined Types (UDTs) on catalog 'Northwind'': Task Completed. Starting task 'Retrieving relational model data for schema 'dbo' in catalog 'Northwind'': Starting subtask: Retrieving sequence meta-data. Subtask completed Starting subtask: Retrieving field meta-data for 24 tables in 1 batches. Subtask completed Starting subtask: Retrieving field meta-data for 21 views in 1 batches. Subtask completed Starting subtask: Retrieving parameter meta-data for 47 stored procedures in 1 batches. Subtask completed Starting subtask: Retrieving resultset meta-data for 1 stored procedures in 1 batches. Subtask completed Starting subtask: Retrieving parameter meta-data for 4 table valued functions in 1 batches. Subtask completed Starting subtask: Retrieving resultset meta-data for 4 table valued functions in 1 batches. Subtask completed Starting subtask: Retrieving meta-data for 0 synonyms in 0 batches. Subtask completed Task Completed. Starting task 'Retrieving all Unique Constraints on catalog 'Northwind'': Task Completed. Starting task 'Retrieving all Foreign Key Constraints on catalog 'Northwind'': Task Completed. Starting task 'Retrieving all Extended Properties on catalog 'Northwind'': Task Completed. Sync completed. Saving refreshed project... Project synced and saved successfully.

Command line: CliSyncWithDatabase.exe 8 1 c:\temp\LLBLGenProjects\NorthwindTut.llblgenproj

Basically the same functionality as CliRefresher, but no validation, it won't stop if export of DDL SQL is needed (that's not going to happen anyway, as it only syncs database oriented elements), 1 DB per run. It also fetches TVFs which the v4.2 one didn't do.

There are some glitches in the logging but that's about it. Again, I can't stress this enough, it's not going to safe you from using the designer as errors and other stuff caused by the refresh will pop up when you feed the saved project to the generator as validation will take place there, but at least you can automate parts of it.

This will do? (v5.4)

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 23-Feb-2018 14:51:41   

Implemented for v5.4

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 23-Feb-2018 15:29:25   

Otis wrote:

Btw, is using the designer such a burden ? It's a couple of clicks and you've refreshed the data, can correct errors etc. I don't see why one would revert back to v4.2 (which has a lot of downsides regarding database first, as it always wants to update the model and won't proceed if there's an error which might be corrected in the database) and not get bugfixes vs use v5, much faster runtime, way less memory consumption etc.... not to mention the other improvements we've made and are coming in v5.4... just because a couple of seconds were needed to run a tool disappointed

I can't say that using your designer is a "burden", that would not be fair as I have not even given your designer a chance. It's just that I'm use to working a certain way and you originally did provide a nice way that fit perfectly into that. I code in the db and my apps. I create tables, write views, procs, etc. I like maintaining all of the db stuff in one place. I do use the SSMS table designer, but everything else I am just writing tsql, and with redgate,intellisense, etc, I think I am efficient. I take LLBL for granted as the silent miracle worker that sits between the db and the app. When creating a new app, I develop on the fly, constantly making database changes. Many many many changes. I work very fast. The few seconds and clicks really do add up, especially considering that before, it was a single click. And it's more than a few seconds and clicks. It's many clicks spread out as I have to wait a few seconds on some steps and there are a few dialogs you put up as well and I have to click a bunch of times to get through those. F5 does not sync. It just opens that screen, then I have to click the button 'Perform Tasks', then another button, etc. Or am I missing a shortcut? Another issue is I'd rather not introduce a new designer and new location into my work style for having to make changes and turn it into a well this change I have to make here, but that change I have to make there, bounce between sql and llbl, and then this stuff goes this way, but the other stuff goes the other way. Do I sometimes get errors with the command line sync and have to go fix them? Yes. But they are rare.

About the only thing I do in the LLBL designer is set the identifying fields for views, # of resultsets on procs, etc. I do not ever tweak any columns, except when I'm helping llbl get back in sync with the db. Some of the errors I get I think could be averted if there was some setting to tell LLBL to "really, I mean it, seriously, just take what the db has, and don't assume anything you have overrides what the db is telling you". I've tweaked all the settings (in 4.2) I can think of and am really close, but sometimes, still have a few issues.

Should I give your new designer a shot? I should. I don't know anything about it. I've just had bad experiences with model 1st. If the app was using the db as a dumb data store and all I needed was tables, then sure, it would work. But as soon as I get to that 1st complex view with complex joins, applys, nested subqueries, case statements, functions, procs, etc and it always does happen, I find myself regretting having wasted time with model 1st and I go back to doing everything in the db 1st.

I switched back to 4.2, because, really, you designed an incredible product. It just works and it works great. Would I love to upgrade to a faster one and one that generates even faster? Of course! Bugs? What? ???? There are bugs in 4.2 framework? I haven't seen any. Or at least when I think I've seen one, it always ends up being me. My only current issue with 4.2 is on one of my projects the db has gotten so big that it takes quite a while to generate. And the resultant dlls are the largest in the project. I am looking fwd to seeing how much faster 5 can generate it.

happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 23-Feb-2018 15:29:57   

Otis wrote:

Implemented for v5.4

You are awesome! I really appreciate that you listen. Looking fwd to trying out 5.4!

THANK YOU SO MUCH!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 25-Feb-2018 09:39:43   

happyfirst wrote:

Otis wrote:

Btw, is using the designer such a burden ? It's a couple of clicks and you've refreshed the data, can correct errors etc. I don't see why one would revert back to v4.2 (which has a lot of downsides regarding database first, as it always wants to update the model and won't proceed if there's an error which might be corrected in the database) and not get bugfixes vs use v5, much faster runtime, way less memory consumption etc.... not to mention the other improvements we've made and are coming in v5.4... just because a couple of seconds were needed to run a tool disappointed

I can't say that using your designer is a "burden", that would not be fair as I have not even given your designer a chance. It's just that I'm use to working a certain way and you originally did provide a nice way that fit perfectly into that. I code in the db and my apps. I create tables, write views, procs, etc. I like maintaining all of the db stuff in one place. I do use the SSMS table designer, but everything else I am just writing tsql, and with redgate,intellisense, etc, I think I am efficient. I take LLBL for granted as the silent miracle worker that sits between the db and the app. When creating a new app, I develop on the fly, constantly making database changes. Many many many changes. I work very fast. The few seconds and clicks really do add up, especially considering that before, it was a single click. And it's more than a few seconds and clicks. It's many clicks spread out as I have to wait a few seconds on some steps and there are a few dialogs you put up as well and I have to click a bunch of times to get through those. F5 does not sync. It just opens that screen, then I have to click the button 'Perform Tasks', then another button, etc. Or am I missing a shortcut?

No that's it. You can execute the 'perform tasks' on that tab with alt-r but that's indeed the procedure. I now have a better understanding how you work simple_smile In v5 you can work in mixed mode btw: model your entities in the designer and sync the rest from the db: the entities will then drive the table creation, which might be done faster in the designer using quickmodel -> sync -> export ddl sql script.

Another issue is I'd rather not introduce a new designer and new location into my work style for having to make changes and turn it into a well this change I have to make here, but that change I have to make there, bounce between sql and llbl, and then this stuff goes this way, but the other stuff goes the other way. Do I sometimes get errors with the command line sync and have to go fix them? Yes. But they are rare.

About the only thing I do in the LLBL designer is set the identifying fields for views, # of resultsets on procs, etc. I do not ever tweak any columns, except when I'm helping llbl get back in sync with the db. Some of the errors I get I think could be averted if there was some setting to tell LLBL to "really, I mean it, seriously, just take what the db has, and don't assume anything you have overrides what the db is telling you". I've tweaked all the settings (in 4.2) I can think of and am really close, but sometimes, still have a few issues.

In v5 that should be over, as it doesn't make any changes to the relational model data if that data is synced from a db. In v4 if you e.g. changed a field or something it could sync that to the relational model data which gave you then the choice to export the ddl sql or forget the changes. This isn't done anymore: it simply doesn't make the changes anymore, so things should flow better from db to model if you want to.

Should I give your new designer a shot? I should. I don't know anything about it. I've just had bad experiences with model 1st. If the app was using the db as a dumb data store and all I needed was tables, then sure, it would work. But as soon as I get to that 1st complex view with complex joins, applys, nested subqueries, case statements, functions, procs, etc and it always does happen, I find myself regretting having wasted time with model 1st and I go back to doing everything in the db 1st.

simple_smile Understood

I switched back to 4.2, because, really, you designed an incredible product. It just works and it works great. Would I love to upgrade to a faster one and one that generates even faster? Of course! Bugs? What? ???? There are bugs in 4.2 framework? I haven't seen any. Or at least when I think I've seen one, it always ends up being me. My only current issue with 4.2 is on one of my projects the db has gotten so big that it takes quite a while to generate. And the resultant dlls are the largest in the project. I am looking fwd to seeing how much faster 5 can generate it.

Thanks simple_smile And bugs? You won't hear it from me cough wink v5.4's generated adapter code is 50% of the generated code in v5.3 so that's serious progress, and generating it is 2-3x faster too. Performance and memory usage compared to v4.2 is also much better (already the case in v5.3) even though v4.2 is already good.

The cli refresher works OK now, it's included in v5.4 so you can continue working as you want to simple_smile

Frans Bouma | Lead developer LLBLGen Pro